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Executive  Summary 


DEFENSE  LOGISTICS  STANDARD  SYSTEMS 
FUNCTIONAL  REQUIREMENTS 

The  Defense  Logistics  Standard  Systems  (DLSS)  make  it  possible  to  effectively 
requisition,  issue,  bill,  ship,  and  account  for  all  DoD  items.  However,  they  have 
become  restrictive  and  technologically  obsolete.  If  effective  exchange  of  logistics 
information  among  the  Services,  Agencies,  and  Field  Activities  is  to  continue,  the 
DLSS  Office  should  update  its  policies,  procedures,  transaction  formats,  and  other 
administrative  processes.  The  Office  must  also  redesign  the  Systems  to  ease  changes 
in  operational  and  informational  requirements. 

The  requirements  for  DLSS  modernization  have  been  specified.  The  specifica¬ 
tion  should  result  in  DLSS:  ( 1)  that  facilitate  the  exchange  of  information  among  the 
Services,  Agencies,  and  Field  Activities,  (2)  with  forms  and  formats  tailored  to 
current  needs,  and  (3)  that  will  encourage  effective  use  of  advances  in  technology. 


ORGANIZATION  OF  THE  REPORT 


The  Defense  Logistics  Standard  Systems  (DLSS)  provide  standard  policies, 
procedures,  and  transaction  formats  to  facilitate  effective  communication  of  logistics 
information  among  Service  and  Agency  logistics  systems.  To  achieve  their  goal,  the 
DLSS  prescribe  logistics  procedures  for  specific  functional  activities  (e.g. 
requisitioning,  billing,  discrepancy  reporting)  and  specify  more  than  400  transaction 
formats.  The  objective  of  the  Modernization  of  DEfense  Logistics  Standard  Systems 
(MODELS)  project  is  to  improve  the  flexibility  and  capabilities  of  DoD  inter-Service 
and  Agency  logistics  operations  and  management  information  communications 
toward  the  goal  of  increasing  overall  effectiveness  of  logistics  management. 

While  the  DLSS  have  been  slowly  evolving  during  the  past  decade,  the 
information  processing  and  communication  industries,  which  support  DLSS 
information  and  communication  requirements,  have  been  improving  in  capability  at 
a  rapid  rate.  As  a  result  of  these  changes,  data  management  techniques  have  been 
improved,  data  processing  is  faster,  methods  of  electronically  communicating 
information  between  organizations  have  been  improved,  and  logistics  managers  now 
have  easier  direct  access  to  electronic  information.  The  combination  of  these 
advances  has  created  an  environment  with  an  increase  in  demand  for  more 
information  to  be  delivered  to  more  logisticians  on  a  more  timely  bases,  in  a  user- 
oriented  format. 

Logistics  activities  to  be  encompassed  by  future  MODELS  information 
communication  standards  and  DLSS  standardized  procedures  are  shown  in  Figure  1. 
The  functions  enclosed  in  solid-lined  boxes  in  Figure  1  are  discussed  in  detail.  (The 
maintenance  function  in  the  dashed  box  is  not  included  because  it  is  addressed  by 
other  DoD  study  teams.)  Each  function  is  analyzed  to  identify  its  component 
activities,  define  each  activity  element,  indicate  the  extent  of  DLSS  procedural 
coverage,  and  state  the  requirement  for  establishment  of  future  DLSS  interfaces 
under  the  MODELS  concept.  The  requirements  are  in  Part  I  of  this  report. 
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FIGURE  1 .  MODELS  FUNCTIONAL  ACTIVITIES 


■'Only  interfaces  are  addressed  in  this  study 


Part  II  discusses  the  following  user  interface  and  information  exchange 
requirements  and  methodologies: 

•  Information  exchange  requirements  that  address  inter-Service/Agency  and 
Service-to-Joint  Activities  requirements 

•  Methods  of  data  organization  and  information  exchange  that  enable  DoD  to 
satisfy  new  logistics  management  information  requirements,  such  as 
interactive  processing,  electronic  mail,  DBMSs,  and  data  standardization 

•  Logistics  management  information  changes,  such  as  logistics  management 
by  weapons  system  and  improvements  in  DoD  asset  visibility,  that  impose 
revised  information  processing  and  communications  requirements  on  the 
DLSS 


•  Further  development  of  DLSS  goals  and  system  conceptual  design  activities 
to  reflect  a  functional  viewpoint  including  all  DoD  logistics  modernization 
projects  within  the  scope  of  DLSS  procedures. 
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Part  HI  of  the  report  discusses  technical  considerations  related  to  meeting  the 
functional  requirements  described  in  Parts  I  and  II.  It  provides  technology 
alternatives  that  will  be  used  to  develop  the  MODELS  conceptual  design  as  follows: 

•  Alternative  communication  network  architectures 

•  Telecommunication  technology  and  cost  issues 

•  Capability  of  distributed  data  management. 

Following  Part  HI  we  present  five  appendices: 

•  Open  Systems  Interconnection  Model  (Appendix  A) 

•  Information  Resource  Management  Plan  Outline  (Appendix  B) 

•  Communications  Traffic  Model  (Appendix  C) 

•  Data  Base  Management  (Appendix  D) 

•  Glossary  (Appendix  E). 

In  summary,  this  report  of  DLSS  functional  requirements  describes  how  new 
information  technology  improvements  affect  (1)  the  need  for  exchanges  of 
information  among  Services  and  Agencies,  and  Field  Activities,  (2)  the  specific  needs 
of  logistics  managers  for  new  forms  and  formats  for  logistics  information,  and  (3)  the 
requirement  for  updated  standards  that  will  encourage  effective  use  of  advances  in 
technology  to  improve  the  exchange  of  information. 
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CHAPTER  A.  SCOPE  OF  THE  MODERNIZED  DEFENSE  LOGISTICS 
STANDARD  SYSTEMS  FUNCTIONAL  ACTIVITIES 


The  scope  of  the  Defense  Logistics  Standard  Systems  (DLSS)  is  prescribed  by 
Department  of  Defense  Directive  (DoDD)  4000.25,  "Administration  of  Defense 
Logistics  Standard  Systems.”  The  logistics  standard  procedures  prescribed  by  DLSS 
publications  are  shown  in  Table  A-l.  To  develop  a  conceptual  design  for  the 
Modernization  of  the  DEfense  Logistics  Standard  Systems  (MODELS),  it  is 
necessary  to  evaluate  the  scope  of  the  DLSS  functions  in  the  overall  Department  of 
Defense  (DoD)  logistics  environment.  Such  an  evaluation  places  the  DLSS  in 
perspective  and  also  highlights  the  requirement  to  expand  the  scope  of  DLSS  to 
include  other  logical  interfaces  and  related  functional  areas.  The  analysis  of  the 
DLSS  scope  of  responsibility  presented  here  must  be  viewed  as  removed  from 
existing  organizational  and  functional  breakdowns. 

Figure  A-l  is  a  functional  activities  work  breakdown  structure  (WBS)  diagram 
for  the  six  second-tier  logistics  functions  consisting  of: 

•  Requirements 

•  Acquisition 

•  Supply 

•  Transportation 

•  Maintenance 

•  Reutilization  and  Marketing. 

Each  of  these  functions  is  described  in  Table  A-2. 

The  scope  of  the  current  DLSS  encompasses  retail  requisitioning,  wholesale 
supply,  transportation,  contract  administration,  finance  (billing),  performance 
measurement  of  time  segments  in  the  supply-transportation  pipeline,  and  logistics 


TABLE  A-1.  DEFENSE  LOGISTICS  STANDARD  SYSTEMS  PUBLISHED  PROCEDURES 


ACRONYM 

PROCEDURE  TITLE 

MILSTRIP 

Military  Standard  Requisitioning  and  Issue  Procedures 

MILSTRAP 

Military  Standard  Transaction  Reporting  and  Accounting  Procedures 

MILSTEP 

Military  Supply  and  Transportation  Evaluation  Procedures 

MILSTAMP 

Military  Standard  Transportation  and  Movement  Procedures 

MILSCAP 

Military  Standard  Contract  Administration  Procedures 

DoDAAD 

Department  of  Defense  Activity  Address  Directory 

M  USB  ILLS 

Military  Standard  Billing  System 

MAPAD 

Military  Assistance  Program  Address  Directory 

MILSPETS 

Military  Standard  Petroleum  System 

(Procedures  for  the  Management  of  Petroleum  Products) 

DAAS 

Defense  Automatic  Addressing  System 

LOGDESMAP 

Logistics  Data  Element  Standardization  and  Management  Program 

ILCS 

International  Logistics  Communications  System 

ROD 

Report  of  Discrepancy 

data  management.  Although  the  MODELS  design  must  cover  these  traditional 
areas,  it  should  also  incorporate  other  logistics  elements  to  form  a  cohesive 
functional  framework  among  DoD  logistics  operations  and  management.  This  WBS 
is  developed  for  the  MODELS  project  to  facilitate  the  functional  analysis  and 
Phase  3  conceptual  design.  It  is  not  intended  as  a  recommendation  for  future  DoD 
logistics  management  operations. 

This  chapter  discusses  issues  associated  with  these  six  primary  functional 
areas,  followed  by  a  detailed  discussion  of  issues  identified  within  each  area. 

Many  logistics  functions  are  not  effectively  interfaced  with  current  DLSS 
procedures,  including:  requirements  planning,  inventory  management  functions 
such  as  stratification  and  stockage  patterns,  warehousing,  retail  (point  of  sale) 
issues,  Continental  United  States  (CONUS)  transportation  outside  the  Defense 


3.4  WHOLESALE 
STORAGE 


TABLE  A-2.  DESCRIPTIONS:  LOGISTICS  FUNCTIONS  ENCOMPASSED  BY  MODELS 


FUNCTIONS 


DESCRIPTIONS 


10 


2  0 


Requirements 


Identification  of  a  need,  supported  by  the  necessary  management  action  and  planning  to 
"project"  that  need  in  terms  of  anticipated  operational  requirements  identification  of  oper 
ational  requirements  is  one  basis  for  the  development  of  logistics  resources  requirements 
Performance  measurement  of  planned  to  actual,  for  both  operational  capability  and 
resources  utilization,  is  a  principal  means  for  improving  future  decisions  and  is  a  primary 
informational  input  to  new  requirements 


Acquisition 


Obtaining  equipment,  supplies,  or  services  by  contract  through  purchase  or  lease,  regardless 
of  whether  the  quantities  to  be  acquired  are  already  in  being  or  must  be  created  developed, 
or  demonstrated  and  evaluated  Acquisition  begins  when  funds  are  allocated  and  appor¬ 
tioned  It  includes  selection  of  sources,  solicitation  award  of  contract,  funding,  contract 
administration,  and  those  technical  and  management  functions  directly  related  to  satisfying 
requirements  by  contract 


3  0 


Supply 


Supply  provides  end  items,  equipment,  and  repair  and  replacement  parts  to  operational  and 
support  units  on  an  as-requested  basis  The  supply  process  begins  with  the  decision  to 
acquire  assets  for  immediate  consumption  or  stockage  against  projected  requirements  The 
decision  is  implemented  by  submission  of  a  requisition  document  into  the  supply  system  if 
the  requested  item(s)  is  not  available  at  the  retail  unit,  the  requisition  is  processed  through 
the  supply  system  to  the  wholesale  inventory  management  function  During  the  requisition¬ 
ing  process,  technical  data  may  be  required  for  initial  item(s)  identification  or  subsequent 
determination  of  acceptable  substitutes  if  the  item(s)  is  physically  available  in  the  DoD 
supply  system,  the  appropriate  storage  facility  is  requested  to  process  the  item(s)  for  ship¬ 
ment  to  the  requisitioner  Thus,  the  supply  function  includes:  (1 )  retail  operations.  (2)  whole¬ 
sale  inventory  management,  (3)  technical  data  management,  and  (4)  wholesale  storage  as 
major  subfunctions  for  this  MODELS  analysis 


4  0  The  activities  related  to  the  movement  of  personnel,  equipment,  and  supplies  in  support  of 

Transportation  military  operations  or  other  requirements  It  includes  planning,  authorization,  routing, 
scheduling,  and  movement  it  also  includes  procurement  of  these  services  from  commercial 
sources 


50 


Maintenance 


Maintenance  includes  tha  process  of  overhauling,  rebuilding,  repairing,  and  replacing 
equipment  and  parts  to  maintain  end  items  and  their  associated  support  equipment  in  a 
state-of-readiriess  to  support  defense  missions  and  objectives  The  function  of  overhaul  and 
maintenance  develops  policies  and  procedures  that  profoundly  affect  supply  management 
policies  and  requirements.  Data  generated  in  maintenance  operations  are  essential  to  sound 
determinations  of  the  range  of  items  carried  in  supply  inventories  and  the  stock  levels  to  be 
maintained  Intelligence  from  maintenance  functions  can  be  invaluable  to  the  supply  man¬ 
ager  for  providing  effective  support  to  the  operating  forces  Maintenance  and  supply  man¬ 
agement  should  be  viewed  as  cooperative  and  integral  teamwork  having  as  its  objective 
maximum  effectiveness  and  efficiency 


60 

Reutilization 
and  Marketing 


The  logistics  processes  associated  with  the  receipt,  classification,  storage,  reutilization,  sale, 
and  disposal  of  property  excess  to  supply  requirements  Basically,  excesses  are  generated 
through  one  of  two  conditions.  The  first  is  obsolescence,  or  the  decrease  in  utility  of 
inventory  assets  as  a  result  of  technological  changes  that  have  brought  about  development 
of  a  new  item  or  end  equipment  that  now  enjoys  the  demand  The  second  cause  is  erroneous 
requirements  input  to  the  computation  process  resulting  in  too  large  a  procurement  for 
either  provisioning  or  replenishments 


Transportation  System  (DTS),  supply  data  file  management,  procurement  proce¬ 
dures,  and  excess  reutilization.  For  example,  transportation  coverage  in  the  DLSS 
has  been  limited  to  DTS  procedures,  performance  tracking,  and  shipment  status  and 
tracking.  The  Military  Traffic  Management  Regulation  (MTMR)  and  Transporta¬ 
tion  Discrepancy  Report  (TDR)  are  external  to  DLSS,  and  yet  their  interfaces  are 
vital  to  effective  accomplishment  of  logistics  operations  and  information  reporting. 

As  another  example,  MILSCAP  established  the  kinds  of  contracting  and 
contract  administration  information  to  be  exchanged  and  the  procedures  for 
exchanging  this  information.  The  procedures  promulgated  in  the  MILSCAP  have 
been  influential  in  the  development  of  the  contracting  and  contract  administration 
systems  within  DoD.  MILSCAP  procedures  also  implement  and  supplement  con¬ 
tracting  and  contract  administration  procedures  prescribed  in  the  Federal  Acquisi¬ 
tion  Regulation  (FAR)  and  Defense  Federal  Acquisition  Regulation  Supplement 
(DFARS).  However,  MILSCAP  has  been  inconsistently  implemented  by  the  Services 
and  Agencies  (S/As).  Reutilization  and  Marketing  (R&M)  is  considered  by  DLSS 
only  for  shipments  to  and  requisitioning  from  Defense  Reutilization  and  Marketing 
Offices  (DRMOs).  Although  this  important  source  of  logistics  inventory  receives 
more  than  3  million  items  annually,  with  original  prices  (i.e.,  current  catalog 
Standard  Price)  totaling  over  $4  billion,  only  16  percent  is  reutilized.  This 
percentage  might  be  improved  substantially  by  full  integration  of  available  DRMO 
information  into  logistics  information  networks  through  MODELS. 

The  MODELS  analysis  considered  the  DLSS  functions  in  the  context  of  overall 
logistics  information  requirements  and  functional  interfaces  including  and  incorpo¬ 
rating  many  functions  not  included  in  the  current  DLSS. 


1-5 


MODELS  Requirement:  Informational  inputs  and  function-to- 
function  interfaces  (for  example,  supply-to-transportation) 
should  be  reevaluated  and  redefined  to  overcome  known  inter- 
S/A  information  deficiencies  not  addressed  by  the  current 
DLSS  and  to  meet  the  needs  of  new  and  expanding  functional 
and  management  information  requirements. 

Figure  A-2  illustrates  the  scope  of  the  MODELS  project  as  perceived  by  the 
project  team  and  shows  the  relationship  of  the  DLSS  to  project  functional  objectives. 
This  illustration  does  not  imply  that  the  DLSS  should  develop  standard  procedures 
for  all  of  these  functions;  rather,  it  reflects  the  need  for  information  exchange 
standards  throughout  DoD  to  ensure  easy,  quick  access  to  information  vital  to  an 
effective,  responsive  logistics  system.  The  Defense  Logistics  Standard  Systems 
Office  (DLSSO),  as  the  organization  assigned  responsibility  to  administer  standard 
logistics  systems  and  programs,  should  have  a  major  role  in  coordinating  the 
implementation  and  interfaces  between  the  many  varied  functions  and  systems 
needed  to  keep  DoD  logistics  systems  in  the  S/As  communicating  with  one  another 
while  taking  maximum  advantage  of  developing  information-processing  tech¬ 
nologies.  The  following  subsections  describe  issues  related  to  the  environment  and 
requirements  for  logistics  information  exchange. 

Throughout  this  report  many  functional  requirements  are  presented.  Each 
requirement  is  offset  like  the  MODELS  Requirement  stated  on  page  1-5. 

A.l  DLSS  Transactions  and  Data  Exchange  Considerations. 

Current  DLSS  standard  transactions  are  difficult  to  change,  often  requiring  a 
year  or  more  to  add  or  change  a  single  data  element,  because  of  the  time  required  for 
S/A  staffing  and  implementation  schedule  coordination.  To  increase  the  scope  of 
DLSS  functional  coverage  and  permit  the  dynamic  information  management  neces 
sary  in  the  DoD  environment,  which  encompasses  organizations  with  different 
missions,  the  DLSS  need  variable-length  and  variable-field  transactions. 
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These  transactions  must  be  usable  in  interactive  as  well  as  batch  processing. 
They  must  also  provide  a  capability  for  Service-unique  data  to  be  carried  (trans¬ 
parent  to  supply  source  and  other  external  processing  points)  or  removed  when  the 
transaction  leaves  the  specific  S/A  environment  and  restored  when  response 
transactions  (e.g.,  requisition  status)  re-enter  the  original  S/A  environment. 
Service-unique  elements  that  apply  in  DoD-wide  common  functions  will  be  prime 
candidates  for  general  inclusion  in  the  system  thereby  improving  all  inter-S/A 
communications  as  well  as  information  exchange  control. 

MODELS  Requirement:  The  MODELS  conceptual  design 
must  provide  flexible  transaction  formats  and  a  methodology 
for  expedited  adoption  of  new  codes  and  procedures  as  logistics 
operations  and  management  information  needs  change.  (This 
characteristic  is  discussed  in  more  detail  in  Part  II,  Sec 
tion  B.2.) 

The  Uniform  Materiel  Movement  and  Issue  Priority  System  (UMMIPS),  which 
is  not  now  within  the  scope  of  DLSS  administration,  provides  the  basic  standards  for 
Force  Activity  Designator  (FAD)  assignment  and  materiel  issue  and  transportation 
prioritization,  as  well  as  the  maximum  time  standards  for  processing  segments,  the 
frequency  of  follow-ups,  and  response  time  frames.  Additional  layers  of  sequencing 
rules  have  developed  and  should  now  be  incorporated  in  UMMIPS. 

MODELS  Requirement:  UMMIPS  performance  measurement 
standards  and  procedures  should  become  part  of  the  restruc¬ 
tured,  expanded  DLSS,  and  must  continue  to  be  closely 
coordinated  with  the  Joint  Chiefs  of  Staff  (JCS)  for  FAD  and 
priority  assignments.  (This  requirement  is  discussed  in  more 
detail  in  Part  I,  Chapter  C.) 

MODELS  will  require  development  of  standard  retention  periods  to  support 
different  types  of  inquiries  and  historical-chain-of-events  reporting.  Those  retention 
standards  will  be  developed  for  on-line  and  batch  files. 

Some  critical  transaction  edits  are  now  performed  by  a  third-party  (DAAS). 
and  edit  and  validation  rules  and  criteria  are  geared  toward  batch  processing. 


Under  MODELS,  value-added  processing  at  a  central  site  may  be  reduced  if  not 
eliminated.  Nodal  or  gateway  processing  may  be  performed  under  standardized 
rules.  Therefore,  supply  source  front-end  edit  and  validation  processing  may  be 
greatly  reduced.  Outright  rejection  of  erroneous  transactions  may  be  replaced  by 
transaction  suspension  with  on-line  inquiry  to  the  transaction  origin  for  near-real- 
time  error  correction.  The  extent  to  which  nodal  or  gateway  processing  can  be  used 
in  improving  logistics  information  flows  still  needs  to  be  determined  although  it  will 
certainly  be  a  factor.  These  issues  are  discussed  in  Part  HI,  Chapter  A  of  this  report. 

MODELS  Requirement:  MODELS  will  require  some  degree  of 

data  base  and  data  model  standardization. 

The  current  DLSS  provide  standard  interfaces  and  accompanying  rules  for 
information  exchange.  The  logistics  system  inputs  and  outputs  need  to  be  defined  as 
standard  information  exchange  requirements,  not  necessarily  specific,  fixed- 
transaction  formats.  However,  the  information  exchange  requirements  need  to  be 
stated  with  standard  data  elements  and  rules  of  recognition.  Alternative  concepts 
for  revised  DLSS  transaction  formats  are  discussed  in  Part  II,  Section  B.2.  MODELS 
may  rely  on  gateway  or  front -end  telecommunications/computer  equipment  process¬ 
ing  to  provide  translation  to  DLSS  standards,  as  transactions  go  to  and  from  S/A 
systems.  In  that  case,  MODELS  would  define  internodal  transactions  for  infor¬ 
mation  exchange  and  event/status  reporting/recording.  This  topic  will  be  analyzed 
in  depth  during  Phase  3  of  the  MODELS  project.  Issues  in  both  telecommunications 
and  distributed  data  base  management  affecting  this  analysis  are  presented  in 
Partm,  Chapters  B  and  C,  respectively. 

The  DLSS  have  traditionally  concentrated  on  external  transactions,  providing 
a  tightly  controlled  framework  for  common  transactions  between  incompatible  sys¬ 
tems.  The  DLSS  were  promulgated  to  overcome  S/A  system  incompatibilities  and 
provide  an  S/A  bridge  but  not  to  supplant  S/A  internal  systems.  However,  because  of 


the  generally  successful  implementation  of  the  DLSS  data  elements,  they  are  at  the 
core  of  every  logistics  system  and  the  internal-versus-external  distinction  is  often 
hard  to  maintain.  Today,  many  internal  S/A  transactions  parallel  the  DLSS. 
Ideally,  internal  S/A  transactions  would  be  completely  replaced  by  the  DLSS.  In 
practice,  however,  internal  transactions  bearing  DLSS  document  identification 
codes  will  also  contain  unique  codes. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
the  capability  for  internal  S/A-unique  data  needs  to  be  accom¬ 
modated  in  DLSS  inter-S/A  transactions. 

Today,  the  internal  S/A  usage  of  DLSS  standards  for  information  exchange  can 
become  a  trap.  When  DLSS  changes  are  mandated,  they  may  undermine  previous 
conforming  internal  usage.  Because  such  internal  usage  does  not  usually  carry  a 
DLSS  blessing,  a  DLSS  change  can  disrupt  S/A  internal  processes  that  are  tied  too 
closely  to  the  former  DLSS  usage.  Internal  S/A  systems  are  to  some  extent  locked 
into  the  current  DLSS  architecture,  and  that  may  become  an  impediment  to  change. 
The  very  success  of  the  DLSS  has  bred  S/A  systems  dependent  on  current  transaction 
formats  and  80-column  records.  In  instances  in  which  DLSS  are  fully  incorporated 
into  S/A  internal  logistics  operation,  the  S/A  will  often  attempt  to  restrict  the  extent 
of  a  DLSS  change  to  protect  its  own  system  maintenance  requirements. 

Generally,  the  S/A  will  choose  to  apply  basic  standards  with  add-on  uniques 
rather  than  implement  totally  nonstandard  methods.  S/A  procedures  of  various 
types  deal  with  basically  common  problems  and  needs.  Some  develop  into  Proposed 
MILSTRJP  Change  Letters  (PMCLs)  and  standard  procedures.  Even  those  that  do 
not  become  standard  tend  to  be  based  on  existing  DLSS  standards.  Under  MODELS, 
a  more  open  transaction  structure  architecture  should  encourage  use  of  standards  in 
internal  S/A  systems.  Service-unique  codes  and  special  transactions  will  not  de¬ 
grade  MODELS-structured  processing  as  long  as  the  Service-uniques  do  not 


supplant  the  DLSS  standards  and  are  not  imposed  on  others.  This  MODELS 
flexibility  should  encourage  gradual  dominance  of  the  DLSS  in  intra-S/A  processes 
without  external  imposition. 

Currently,  arrangements  between  two  or  more  S/As  are  used  to  handle  logistics 
interfaces  and  information  exchange  requirements.  Most  occur  because  the  need  is 
restricted  to  the  two  parties  or  because  the  DLSS  either  cannot  respond  to  the  need 
or  would  take  too  long  to  change  to  meet  the  need.  These  agreements  between  S/As 
handle  interfaces  and  information  requests  not  covered  by  the  DLSS.  However, 
some  of  these  agreements  are  common  requirements  throughout  the  logistics  com¬ 
munity.  It  would  be  beneficial  to  the  DLSS  to  accommodate  such  interfaces  under 
MODELS,  providing  visibility  as  well  as  a  springboard  for  eventual  standardization. 

MODELS  Requirement:  MODELS  transaction  formats  must 
provide  flexibility  to  handle  two-party  and  multi-party  infor¬ 
mational  exchanges,  even  though  not  formally  part  of  DLSS 
procedures. 

Informational  outputs  from  supply  sources  and  other  processing  points  (e.g., 
contract  abstracts,  materiel  release  confirmations)  are  also  prescribed  by  DLSS.  In 
addition  to  issues  regarding  inputs  and  interfaces,  other  issues  apply  to  output  trans¬ 
actions: 

•  Outputs  must  continue  to  include  standard  core  data. 

•  The  MODELS  concept  must  consider  pull-and-push  information  needs  sepa¬ 
rately. 

•  On-line  inquiry  capability  must  be  provided. 

MODELS  Requirement:  A  standard  DoD  logistics  data  ele¬ 
ments  dictionary  will  be  a  requisite  (and  a  responsibility  of  the 
DLSS);  it  will  have  to  include  all  data  elements,  terms,  and 
definitions  used  in  S/A  logistics  system  interfaces  and  infor¬ 
mation  exchanges.  The  basis  for  this  dictionary  should  be 
LOGDESMAP. 


A.2  Requirements  Drivers. 

Current  DLSS  are  designed  to  provide  interfaces  and  information.  The 
MODELS  concept  must  consider  the  users  of  logistics  information  and  the  require¬ 
ments  of  customers. 

Current  DLSS  are  not  structured  to  allow  for  differences  in  the  mission  or 
nature  of  user  activities.  MODELS  needs  to  recognize  these  distinctions.  For 
example,  at  base/unit  locations,  such  concerns  as  procurement  leadtime  and  safety 
level  are  shared  with  wholesale  organizations.  This  is  particularly  true  for  locally 
purchased  items,  including  items  on  the  General  Services  Administration  (GSA) 
schedule  and  critical  items  on  backorder.  Therefore,  retail  levels  should  be  consid¬ 
ered  in  the  overall  inventory  management  picture. 

MODELS  Requirement:  Modernized  DLSS  must  provide  for 
standardization  of  retail  procedures. 


In  crisis  or  wartime  situations,  deployment  and  resupply  become  critical.  Iden¬ 
tification,  allocation,  and  tracking  of  selected  materiel  are  the  main  issues,  and  the 
ability  to  divert  selected  critical  materiel  may  be  desirable.  Force  requirements 
should  be  translated  into  supply  sustainment  terms.  The  present  plan  to  batch- 
release  resupply  requirements  according  to  contingency  plans  needs  to  be  addressed; 
the  most  effective  resupply  procedures  in  light  of  available  technology  must  be 
accommodated  in  the  MODELS  conceptual  design.  Also,  the  option  should  exist  to 
allocate  assets  under  several  different  criteria,  such  as  theater  of  operations,  selected 
high  priority  projects,  or  selected  field  units,  ships,  or  activities. 
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MODELS  Requirement:  The  MODELS  concept  must  coordi- 
nate  with  all  S/A  logistics  modernization  requirements.  It 
must  also  be  able  to  satisfy  logistics  information  requirements 
and  fully  support  resupply  requirements  in  crisis  or  wartime 
situations. 

A.3  Logistics  Interfaces. 

The  DLSS  are  concerned  with  interfaces  between  logistics  functions  and 
logistics  organizations,  primarily  where  S/A  lines  are  crossed.  Traditionally,  S/As 
have  insisted  on  the  prerogative  to  develop  and  use  different  and  often  unique 
internal  transactions.  This  prerogative  has  been  justified  by  the  assertion  of 
differing  organizational  activities  based  on  differing  missions.  Naturally,  data 
architectures  and  file  structures  that  reflect  these  unique  traits  have  developed. 
Although  current  DLSS  have  served  to  bridge  these  differences  by  forcing  external 
transactions  into  rigid  molds,  this  solution  limits  interoperability  and  causes  the 
omission  of  unique  data.  Some  interfaces  that  are  omitted  under  the  current  DLSS 
should  be  included  under  MODELS. 

MODELS  Requirement:  The  MODELS  conceptual  design 
should  accommodate  all  information  exchanges  between  inter- 
S/A  logistics  functions  and  operational/management  compo¬ 
nents. 


CHAPTER  B.  PERFORMANCE  MEASUREMENT 
FUNCTIONAL  REQUIREMENTS 


This  first  MODELS  Five-year  planning  horizon  addresses  only  the  Require¬ 
ments  logistics  function  activities  encompassed  by  performance  measurement.  The 
other  two  Requirements  functions,  Requirements  Planning  and  Requirements 
Determination,  particularly  as  related  to  secondary  items,  should  be  considered  in 
the  scope  of  MODELS  for  a  mid-1990s  modernization  program. 

Performance  measurement  is  the  process  of  evaluating  past  logistics  opera¬ 
tions,  and  in  logistics,  as  in  any  discipline,  it  is  the  cornerstone  of  effectiveness.  To 
manage  logistics  resources  effectively,  management  of  every  logistics  process  at  all 
levels  must  have  continual  access  to  timely  performance  indicators.  Performance 
measurement  data  may  come  from  many  sources  as  long  as  the  data  are  accurate, 
timely,  accessible,  consistent  between  organizations,  and  in  usable  and  under 
standable  form.  Historically,  throughout  DoD,  logistics  performance  measurement 
data  have  been  defective  in  at  least  three  of  these  five  areas  —  timeliness,  consis 
tency,  and  accessibility. 

Lack  of  timeliness  and  accessibility  of  DoD  logistics  performance  measurement 
data  is  usually  a  function  of  limited  automatic  data  processing  (ADP)  resources  and 
data  communications.  Most  data  available  for  performance  measurement  are  now 
provided  to  logistics  managers  in  an  off-line  mode.  Much  of  the  data  are  many  days 
or  even  months  old  and  are  either  inaccessible  or  accessible  in  unusable  formats 
only.  In  many  cases,  the  data  needed  for  immediate  identification  of  performance 
deficiencies  and  application  of  corrective  measures  never  reach  the  appropriate 
managerial  levels.  Problems  go  unnoticed,  with  their  causes  never  ascertained 
because  no  performance  indicators  are  available. 


Performance  indicators  and  reports,  as  defined  in  MILSTEP,  have  been  stan¬ 
dardized  throughout  DoD.  However,  each  S/A  has  its  own  way  of  measuring 
performance,  as  does  every  organizational  and  functional  activity.  Accordingly, 
flexibility  in  the  use  of  performance  measurement  data  is  not  only  desirable  but 
necessary.  Standard  presentation  formats  must  be  available.  However,  even  stan¬ 
dard  reports  should  be  easy  to  tailor  and  revise  to  meet  special  information  require 
ments  or  changing  management  requirements  on  a  timely  (1—2  months)  basis. 

Flexibility  for  the  purpose  of  measuring  performance  requires  on-line  access  to 
logistics  data  throughout  DoD,  factored  by  such  characteristics  as  weapons  system, 
commodity/class,  type  of  activity,  or  other  groupings  desired  by  management.  These 
factored  groupings  should  be  accessible  to  managers  at  appropriate  levels  for  all 
DLSS  functional  areas  in  unrestricted  formats,  without  any  need  for  extensive 
resources  or  expertise  in  special  software  programming.  This  means  that  standard 
ized  performance  measurement  data  should  be  available  through  an  easy-to-use,  on¬ 
line,  menu-driven  capability.  Only  the  owner  of  the  data  base  should  be  L  :le  to 
restrict  access  to  the  information  and  then  only  for  reasons  of  security  or  protection 
of  proprietary  rights. 

MODELS  Requirement:  The  MODELS  concept  should  include 
the  capability  to  (1)  accumulate  performance  characteristic 
data  generated  as  a  normal  process  of  daily  operations,  and 
(2)  provide  for  the  retrieval  of  performance  data  in  a  form  that 
the  intended  recipient  will  find  most  useful.  This  capability 
should  include  collection  of  data,  based  on  normally  generated 
operations  data  (not  special  data  collection  efforts),  and  rapid 
retrieval  in  easily  modified  formats,  to  view  information  from 
different  points  of  interest. 


Performance  measurement  requirements  can  be  divided  into  five  functional 
areas:  (1)  retail  inventory  management,  (2)  wholesale  inventory  management, 
(3)  supply-transportation  pipeline,  (4)  contracting,  and  (5)  weapons  system  manage¬ 
ment.  This  structure  is  shown  in  Figure  B-3  and  described  along  with  other  WBS 
functions  in  Table  B-3. 

B.l  Retail  Inventory  Management. 

At  the  retail  level,  managers  are  tasked  to  support  specific  base- level  require 
ments.  These  base-level  requirements  must  be  continually  satisfied  without  signif¬ 
icant  interruption.  Performance  measurement  is  a  key  to  these  logistics  support 
efforts  in  that  adverse  trends  must  be  detected  and  corrected  before  serious  negative 
effects  result.  Similarly,  positive  trends  must  be  identified  and  analyzed  to  make 
sure  they  continue. 

Two  classical  factors  for  measuring  performance  in  retail  inventory  manage 
ment  are  fill-rate  and  inventory  turnover  rate.  In  combination,  these  two  measure 
ments  can  act  as  a  check  and  balance,  in  that  neither  rate  should  move  beyond 
predefined  upper  and  lower  boundaries.  Additional  performance  measurement 
criteria  must  be  defined  to  encourage  effective  weapons  system  management  (see 
Part  II,  Section  C.l).  Sound  performance  indicators  at  the  retail  level  have  a 
profound  and  cost-beneficial  effect  throughout  the  logistics  system.  Therefore,  it  is 
important  that  timely,  accurate  measures  be  prepared  and  distributed  throughout 
the  command  chain.  In  addition,  comparisons  with  other  retail  activities  having 
similar  operations  should  be  performed  for  evaluation  of  resulting  indicators  and 
broader  dissemination  of  good  management  techniques. 

MODELS  Requirement:  The  MODELS  concept  should  include 
methods  for  collecting  and  reporting  data  at  the  retail  opera 
tions  level  to  satisfy  a  variety  of  performance  measurement 
criteria. 


FIGURE  B-3  PERFORMANCE  MEASUREMENT  FUNCTIONS 


TABLE  B-3.  DESCRIPTIONS:  PERFORMANCE  MEASUREMENT  FUNCTIONS 


FUNCTIONS 

DESCRIPTIONS 

1.0 

Requirements 

Identification  of  a  need,  supported  by  the  necessary  management  action  and  planning  to  "project" 
that  need  in  terms  of  anticipated  operational  requirements.  Identification  of  operational  require¬ 
ments  is  one  basis  for  the  development  of  logistics  resources  requirements  Performance  measure¬ 
ment  of  planned  to  actual,  for  both  operational  capability  and  resources  utilization,  is  a  principal 
means  for  improving  future  decisions  and  is  a  primary  informational  input  to  new  requirements. 

1.1 

Plans 

Identification  of  what  items  are  necessary  or  are  likely  to  be  necessary  for  procurement  in  a  future 
time  period  to  support  various  defense  missions.  It  ensures  the  proper  consideration  of  prime 
equipment  and  its  associated  support  on  an  integrated  basis  Logistics  planning  functions  include 
interpreting  system  requirements  for  design  supportability  and  logistics  support,  identifying 
program  functions  and  tasks,  identifying  funding  sources  and  preparing  cost  estimates,  and 
defining  the  organizational  structure  responsible  for  implementation  of  the  tasks  identified 

1  2 

Requirements 

Determination 

Development  of  basic  inventory  requirements  for  equipment,  spare  parts,  and  other  items  to 
support  operating  systems  throughout  their  expected  life-cycle  Composed  of  initial  provisioning 
and  replenishment  phases,  requirements  determination  includes  development  and  execution  of 
basic  stockage  policy,  forecasting  of  demand  and  leadtime,  derivation  of  required  levels  of  inven¬ 
tory,  and  management  of  nondemand-based  items  Considerations  include  interfaces  with  each 
maintenance  level  and  each  geographical  location  where  spare/repair  parts  are  stocked  or  distrib¬ 
uted,  spares  demand  rates  and  inventory  levels,  procurement  leadtimes,  and  methods  of  distri¬ 
bution 

1  3 

Performance 

Measurement 

Comparison  of  current  performance  with  pre-established  mission  objectives  or  goals  The  extent 
and  degree  of  monitoring  required  depends  upon  the  size,  complexity,  and  urgency  of  the  project 
Supply  performance  goals  are  established  by  the  DoD  Components  Supply  system  response  time 
standards  are  stated  in  UMMIPS  procedures.  Separate  performance  goals  may  be  established  for  a 
category  of  items,  a  type  of  activity,  or  a  special  management  grouping 

1  3  1 

Retail 

Inventory 

Management 

Effective  control  procedures  enable  the  retail  supply  level  to  limit  the  number  of  items  on  hand  to 
those  needed  for  immediate  and  projected  requirements.  A  principal  difficulty  is  that  of  fore¬ 
casting  future  requirements  with  a  reasonable  degree  of  accuracy.  Determination  of  the  quantity 
of  any  given  item  required  to  meet  future  needs  is  affected  by  such  considerations  as  cost,  rate  of 
use.  reparability.  rate  of  obsolescence,  and  records  of  past  usage  essentially,  inventory  control 
involves  analysis  and  interpretation  of  these  data,  recognition  of  trends,  and  determination  of  the 
desired  stock  level 

1  3.1  1 

Base-Level 

Stratification 

Once  the  process  of  requirement  determination  is  made  for  an  item  for  every  purpose,  it  becomes 
necessary  to  combine  all  these  data  and  develop  a  single  requirement.  The  method  by  which  this  is 
accomplished  is  called  base-level  stratification  The  basic  principle  is  to  compare  inventory  assets  to 
authorized  levels  and  price  out  the  deficiencies  and  overages  in  the  various  strata  elements  The 
conditions  portrayed  by  the  collective  data,  as  well  as  individual  item  condition,  can  highlight 
stewardship  at  the  retail  level  and.  to  a  degree,  at  the  wholesale  level 

1.3.1  2 

Excess 

Disposition 

Excess  is  determined  by  application  of  economic  retention  criteria  during  the  periodic  process  of 
requirements  determination  The  retention  formula  shows  at  what  period  the  cost  of  retaining  an 
item  is  equal  to  the  cost  of  disposing  of  it  with  the  knowledqe  that  procurement  may  still  be 
necessary  at  a  later  date  Retention  costs  include  storage  space,  care  and  preservation,  stock 
surveillance,  deterioration  in  storage,  and  obsolescence  On-hand  balances  above  the  retention 
limit  are  categorized  as  excess  and  are  subject  to  the  various  screening  and  utilization  processes  of 
the  DoD  R&M  Program  Excess  property  is  shipped  from  the  retail  level  to  the  wholesale  level.  as 
directed  by  the  wholesale  inventory  management 

1  3  2 

Wholesale 

Inventory 

Management 

The  process  of  determining  the  appropriate  range  and  quantity  of  items  that  will  be  carried  in 
inventory  at  DoD  depots  and  storage  locations  The  inventory  control  points  (ICPs)  receive  require¬ 
ments  from  customers  to  stock  specific  line  items  to  support  special  projects  or  programs  (non¬ 
demand  based  items/levels)  Stock  levels  are  periodically  reviewed  based  on  recent  historical 
demand,  and  the  range  and  quantity  of  inventory  is  adjusted  accordingly  inventory  items  are 
prioritized  by  essentiality,  and  final  levels  are  determined  by  available  funding 

TABLE  B-3.  DESCRIPTIONS:  PERFORMANCE  MEASUREMENT  FUNCTIONS  (CONTINUED 


FUNCTIONS 

DESCRIPTIONS 

13  2  1 

Physical 

Inventory 

Management 

The  receipt,  stowage,  and  accountability  of  all  materiel  The  examination,  verification,  and  accep 
tance  of  materiel  are  included  m  the  process  of  receiving  materiel  Materiel  is  weighed,  cubed,  and 
sized  upon  receipt  and  assigned  a  storage  location  that  conforms  to  these  specifications  as  well  as 
consideration  of  hazard,  security,  and  pilferable  items,  and  item  demand  frequency  Based  on 
Materiel  Release  Orders  (MROs),  materiel  is  picked  and  forwarded  to  shipping  for  distribution 
Detailed  accounting  records  are  maintained  by  both  the  ICP  and  the  depot  The  ICP  maintains  tne 
official  property  accountability  record.  Physical  inventory  counts  are  performed  at  the  request  of 
the  accountable  activity  (ICP)  or  when  potential  or  known  record  discrepancies  exist  or  are 
discovered  by  either  the  ICP  or  depot 

1  3  2.2 

Disposal 

Management 

The  functions  of  determining  what  portions  of  inventory  can  be  economically  retained  and  what 
should  be  declared  excess  belong  to  the  iCPs  in  the  Services  and  to  the  Defense  Logistics  Agency 
(DLA)  Item  managers  are  responsible  for  determining  retention  limits  during  the  process  of 
requirements  determination.  Excesses  are  determined  by  the  ICPs  using  economic  retention  criteria 
as  part  of  the  process  of  requirements  determination  The  retention  formula  shows  when  the  cost 
of  retaining  an  item  is  equal  to  the  cost  of  disposing  of  it,  with  the  knowledge  that  procurement 
may  still  be  necessary  at  a  later  date  Retention  costs  include  storage  space,  care  and  preservation, 
stock  surveillance,  deterioration  in  storage,  and  obsolescence  On-hand  balances  above  the 
retention  limit  are  categorized  as  excess  and  are  subject  to  the  various  screening  and  utilization 
processes  of  the  DoD  R&M  Program 

1  3  3 

Pipeline 

Performance 

A  few  exceptional  types  of  supply  actions  are  not  subject  to  MILSTEP  measurement,  but  basically 
the  system  applies  to  all  supply  transactions  requisitioned  from  ICPs  and  shipped  from  Government 
wholesale  stocks,  including  GSA,  to  DoD  activities  within  CONUS  and  from  there  to  overseas  air  and 
water  ports  of  debarkation  MILSTEP  measures  total  pipeline  performance  from  the  date  of  the 
requisition  to  the  date  materiel  is  offered  to  the  consignee's  transportation  officer  or  delivered  to 
the  parcel  post  addressee.  Receipt  takeup,  an  integral  part  of  the  supply-issue-transportation 
process,  is  also  measured  as  a  discrete  segment.  In  the  case  of  overseas  shipments  through  DTS, 
measurement  now  stops  when  materiel  is  discharged  at  the  point  of  discharge  or  lifted  from  the  air 
port  of  discharge  in  the  DoD  system  of  performance  measurement,  MILSTEP  methods  are  used  to 
evaluate  actual  performance  against  the  UMMIPS  time  standards 

1  3  3.1 

Inventory 
Control  Point 

The  ICPs  record  the  time  of  receipt  of  all  customer  requisitions  Comparisons  of  this  time  with  the 
date  of  requisition  preparation  (an  integral  part  of  the  requisition  number)  reveal  the  amount  of 
time  taken  for  the  cycle  segment-requisition  submission  The  ICPs  and  depots  automatically  record 
the  time  when  their  portion  of  the  process  has  been  completed,  and  these  time  factors  provide  me 
means  to  determine  actual  processing  times  used  by  wholesale  supply  activities  Many  other  iCP 
activities  are  measured  by  individual  organization  directive  but  are  not  now  standardized  through¬ 
out  DoD 

1  3  3  2 

Depot 

The  depots  automatically  record  the  time  when  their  portion  of  the  process  has  been  completed, 
and  these  time  factors  provide  the  means  to  determine  actual  processing  times  used  by  wholesale 
supply  activities  Many  other  depot  activities  have  performance  measurement  standards  as  directed 
by  respective  S/A  requirements  However,  these  measurements  are  not  now  standardized  through¬ 
out  DoD 

1  3  3  3 

Transportation 

To  determine  transportation  performance,  shipping  activities  produce  a  series  of  m-transit  data 
records  These  m-transit  data  cards  (IDCs)  are  designed  to  measure,  in  terms  of  time,  the  receipt 
and  subsequent  lift  of  a  shipment  through  each  transportation  node  This  includes  the  shipper 
(storage  location  or  vendor),  each  intermediate  point  of  rest  (transshipment  mode'  carrier)  on  the 
route,  and  receipt  by  the  customer  (at  the  receipt  dock)  The  IDC  accompanies  other  shipping 
papers  along  the  entire  transportation  route  After  materiel  delivery,  the  IDC  is  used  to  interface 
with  its  corresponding  supply  data  to  provide  the  transportation  measurements  for  total  pipeline 
performance  effectiveness,  as  required  by  UMMIPS 

13  3  4 

Commercial 

Contractors 

Most  materiel  and  equipment  is  produced  by  and  acquired  from  commercial  vendors  through  con¬ 
tracts.  These  contracts  prescribe  the  mater  el  to  be  delivered  to  the  Government,  including 
quantity,  technical  specification,  testing  requirements,  and  date  and  location  for  delivery  in  con 
tracts  where  progress  information  is  necessary,  the  two  factors  of  interest  are  the  actual  progress 
toward  completing  the  work  and  the  funds  spent  to  achieve  that  progress  Other  contracts 
performance  measurements  may  include  the  commercial  contractors  attainment  of  contractual 
obligations  such  as  schedule,  quantity,  and  quality 

13  3  5 

Theater/Base 

Upon  receipt,  the  customer  completes  the  IDC  with  "date  received"  and  dispatches  it  to  the  central 
data  collection  pomt  by  the  Automatic  Digital  Network  (AUTODIN)  for  use  m  calculating  me 
m-transit  time  period  Thus,  the  loop  is  closed  and  the  MILSTEP  system  can  determine  whether  me 
customer  received  timely  fulfillment  of  his  requisition  and  the  amount  of  time  reauired  for  each 
segment  of  the  supply  pipeline 

TABLE  B-3.  DESCRIPTIONS:  PERFORMANCE  MEASUREMENT  FUNCTIONS  (CONTINUED 


FUNCTIONS 

DESCRIPTIONS 

13  4 

Contracting 

One  of  the  principal  controls  on  military  contracting  is  exercised  through  the  appointment  of 
contracting  officers  The  authority  to  execute  and  administer  contracts  is  derived  from  the  Dasic 
authority  vested  by  statute  in  the  Secretaries  of  the  Military  Departments  A  contracting  officer 
whose  primary  responsibility  is  to  enter  into  contracts  is  called  a  procurement  contracting  officer 
(PCO),  a  contracting  officer  whose  primary  responsibility  is  to  administer  contracts  s  called  an 
administrative  contracting  officer  (ACO)  In  addition,  a  contracting  officer  responsible  for  termina¬ 
tion  and/or  settlement  of  terminated  contracts  may  be  referred  to  as  the  termination  contracting 
officer  (TCO)  A  single  contracting  officer  may  be  responsible  for  duties  m  any  or  all  of  these  areas 
The  contracting  officer  actually  functions  as  the  leader  of  a  team  of  experts  whose  advice  and 
counsel  cover  the  entire  contract  area  The  team  members  include  engineers,  auditors,  price 
analysts,  lawyers,  quality  assurance  specialists,  transportation  specialists,  negotiators,  and  others  as 
necessary  -  all  specialists  m  their  fields 

13  4  1 

Procurement 

The  acquisition  of  materiel,  equipment,  or  services  from  commercial  vendors  through  competitive 
or  negotiated  purchase  orders  or  contracts.  Procurement  requirements  and  specifications  are 
developed  and  defined  by  the  technical  program  personnel  The  procurement  process  is  performed 
by  a  designated  PCO  Many  aspects  of  the  procurement  process  can  be  measured  for  effectiveness, 
including  procurement  leadtime,  level  of  competitive  procurements,  procurements  awarded  to 
small  or  minority-owned  businesses,  and  number  and  dollar  value  of  unpriced  orders  placed  by  iCPs 

13  4  2 

Contract 

Administration 

Performance  management  of  a  contract  is  the  primary  responsibility  of  the  contract  administration 
office  located  at  the  contractor's  plant  An  ACO  at  the  contract  administration  office  is  assigned 
one  or  more  contracts  to  serve  as  the  focal  point  for  all  field  matters,  administrative  as  well  as 
technical  A  team  of  specialists  is  available  to  provide  support  in  meeting  this  responsibility 
Among  the  continuing  functions  of  contract  administration,  the  most  important  are  surveillance  of 
the  contractor's  progress  toward  completion,  as  well  as  maintenance  of  a  constant  flow  of  informa¬ 
tion  to  the  procuring  activity  on  the  status  of  contracts  The  performance  evaluations  measure 
performance  against  schedule  for  such  major  elements  in  the  production  cycle  as  planning, 
subcontracting,  material  purchase,  plant  set-up,  tooling,  component  manufacture,  subassembly, 
final  assembly,  testing,  and  delivery  The  extent  and  degree  of  monitoring  required  on  a  particular 
contract  depends  on  the  size,  complexity,  and  urgency  of  the  project.  On  specific  cost- 
reimbursement  contracts  and  on  limited  numbers  of  others,  the  monitoring  of  incurred  costs  and 
other  selected  financial  data  is  an  important  means  of  assessing  contract  progress  and  maintaining 
close  surveillance. 

1  3  5 

Interfund 

Billing 

An  automated  billing  and  fund  transfer  system,  under  which  a  billing  office  forwards  an  automated 
billing  (detail  billing  records,  a  summary  billing  record,  and  the  necessary  fund  transfer  nforma- 
tion)  to  a  billed  office  During  the  same  month,  the  billing  office  advises  its  central  accounts  office 
of  the  mterfund  transfers  (self-reimbursements)  it  has  made  The  central  accounts  off'ce  reports 
these  transactions  to  the  U  S  Treasury  and  tc  the  central  accounts  office  of  the  office  whose  funds 
have  been  disbursed  The  billed  office's  central  accounts  office  maintains  a  suspense  file  to  ensure 
that  the  charge  is  cleared  The  billed  office,  through  processes  unique  to  each  Military  Department 
clears  interfund  disbursements  by  either  accepting  the  charge  or  taking  action  to  have  the  billing 
office  reverse  the  transfer 

1  3  6 

Weapons 

Systems 

Management 

The  weapons  systems  logistics  plan  leads  directly  to  scheduling  of  the  various  logistics  activities 
such  as  purchase  of  repair  parts  and  modification,  overhaul,  and  repair  These  schedules  are  used 
to:  contract  with  industry  for  spares;  program  aircraft,  engines,  ships,  and  accessories  for  overhaul 
and  modification,  and  place  with  industry  the  work  that  cannot  be  accomplished  m  Service 
facilities.  As  these  actions  are  taken,  feedback  is  provided  to  the  logistics  support  manager  who  can 
determine  whether  schedules  are  being  met  and  what  measures  may  be  needed  to  overcome 
delays  The  jroject  manager  is  responsible  for  managing  a  high-priority  weapons  system  or  maior 
item  of  equipment  through  all  stages,  from  research  and  development  (R&D)  until  delivery  to  the 
using  unit.  The  recent  emphasis  on  weapons-system-onented  logistics  management  may  create  a 
demand  for  weapons-system-oriented  inventory  managers  (IMs)  at  S/A  iCPs  responsible  for  manag¬ 
ing  a  weapons  system  or  major  item  of  equipment  after  it  is  deployed  to  using  units 

';! 
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DESCRIPTIONS 

13  6  1 

Operational 

Availability 

Planning 

Except  for  ships  and  submarines,  a  weapons  system  is  considered  operationally  available  if  it  is  "Full 
Mission  Capable"  as  defined  in  DoOl  7730  25  A  naval  surface  or  subsurface  weapon  system  is 
operationally  available  if  it  does  not  have  an  outstanding  Casualty  Report  (CASREP)  under  the  Navy 
Casualty  Summary  Reporting  System  Operational  availability  is  usually  defined  as  weapons  system 
uptime  divided  by  total  weapons  system  availability  time  The  rates  for  a  type  of  weapons  system 
are  the  averages  of  the  rates  for  individual  weapons  systems  of  that  type  m  the  operational 
inventory  Weapons  systems  undergoing  scheduled  overhaul  should  not  be  counted  in  the  opera 
tional  inventory. 

Operational  availability  planning  requires  every  major  function  of  the  logistics  process  to  reorient 
from  a  commodity-oriented  perspective  Performance  measurements  related  to  weapons-system- 
identified  items  will  need  to  be  segregated  with  different  standards  of  excellence  applied 
Standards  for  supply  response  time,  backorders,  and  fill  rates  should  be  based  on  optimization 
analysis  to  determine  the  performance  necessary  to  support  end -item  availability  requirements 

1  3  6.2 

Resource 

Allocation 

This  function  within  a  weapons-system-management-oriented  logistics  environment  directs  a  shift 
from  the  traditional  objective  of  meeting  commodity  fill  rate  goals  to  the  objective  of  meeting 
weapons-system-operational  availability  goals  This  may  dictate  development  of  multiechelon 
optimization  models  that  will  generate  inventory  requirements  for  wholesale,  intermediate,  and 
consumer  levels  to  support  weapons  system  availability  goals  at  minimum  cost  The  quality  of 
indenture  and  essentiality  data  in  the  modeling  programs  is  crucial  to  optimization  models  Also, 
optimization  models  make  the  collection  of  accurate  supply  response  time  data  particularly 
important 
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B.2  Wholesale  Inventory  Management. 

At  the  wholesale  level,  IMs  support  a  specific  weapons  system  or  commodity. 
That  support  must  be  provided  on  a  continual  basis.  Again,  performance  measure¬ 
ment  is  one  key  to  success  in  this  area,  in  that  trends  must  be  identified  and 
evaluated  for  the  sake  of  informed  decision-making.  Wholesale  managers  need  on¬ 
line  access  to  applicable  logistics  data  including  vendor  production  and  delivery 
schedules,  wholesale  and  retail  stock  levels,  and  turn-around  times  for  reparables. 
They  also  need  periodic  updates  on  training  and  exercise  plans,  and  retail-level 
performance  indicators  if  they  are  to  be  held  accountable  for  effective  inventory 
management.  Support  objectives  must  be  continually  measured  against  current 
performance  levels  so  that  appropriate  management  decisions  can  be  made.  In 
addition  to  current  MILSTEP  performance  indicators,  wholesale-level  disposal 
management  indicators  should  be  developed  and  implemented.  This  should  include 
analysis  of  performance  related  to  R&M  objectives  worldwide. 
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MODELS  Requirement:  The  MODELS  concept  design  should 
make  it  easy  to  measure  the  performance  of  a  range  of  opera¬ 
tions  and  trend  indicators  at  the  wholesale  operations  level. 


B.3  Pipeline  Performance. 

Pipeline  performance  measurement  is  analyzed  by  logistics  managers  at  all 
levels.  The  MODELS  redesign  needs  to  recognize  the  need  to  measure  pipeline  time 
on  all  supply  requisitions  (worldwide)  from  the  time  of  (customer)  request  to  the  time 
of  receipt  takeup  by  the  customer.  Customers  must  include  both  replenishment 
stock  supply  offices,  maintenance  and  repair  depots,  and  base/unit  supply  or  mainte¬ 
nance  offices.  Pipeline  times  will  be  measured  against  the  UMMIPS  standards. 

These  pipeline  times  should  be  measurable  incrementally  to  define  interval 
pipeline  times  to  include  as  a  minimum  (l)time  from  submission  of  requisition 
transaction  to  receipt  of  requisition  transaction  at  source  of  supply;  (2)  time  for  ICP 
supply  processing  and  depot  processing;  (3)  shipping  time  in  transit  from  the  storage 
point  to  the  requisitioner  (for  overseas  shipments  this  time  includes  time  to  port  of 
embarkation,  time  to  port  of  debarkation,  and  time  from  port  of  debarkation  to  requi¬ 
sitioner);  (4)  time  spent  in  the  contracting  process;  (5)  time  in  transit  from  the  vendor 
to  the  depot  or  other  storage  point;  (6)  time  in-transit  from  the  vendor  to  the 
customer  when  the  vendor  is  tasked  to  ship  directly;  (7)  time  in  transit  for  lateral 
support  redistribution  transfers;  and  (8)  time  in  processing  from  the  receipt  dock  to 
the  receipt  takeup  by  the  customer  (or  until  the  materiel  is  stowed  for  stock  replen¬ 
ishment).  Additional  segment  measurements  should  be  included,  as  appropriate 
(reference  U.S.  Army  Direct  Supply  Support/Air  Line  of  Communication  [DSS/ 
ALOC]  standards). 

Performance  measurement  of  individual  interval  pipeline  times  is  necessary  to 
maintain  visibility  and  control  for  management  evaluation  of  each  leg  of  transit  so 
that  appropriate  actions  and  management  decisions  are  applied  toward  the  correct 
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transit  factor.  Pipeline  data  should  be  available  through  common,  easy-to-use,  ; 

< 

on-line,  menu-driven  processing  facilities  with  access  to  the  data  restricted  only  by  I 

the  data  owner’s  need  for  security  on  specified  information. 

MODELS  Requirement:  The  MODELS  concept  should  identify 

methods  and  procedures  to  collect  pipeline  performance  mea-  j 

surement  data  at  each  segment  of  the  process  as  it  occurs.  The  ' 

DLSS  should  standardize  the  definition  of  each  pipeline  seg¬ 
ment. 

An  important  component  of  the  pipeline  process  is  the  identification  of  various 
types  of  supply,  transportation,  and  product-quality  discrepancies.  In  consolidating 
all  logistics-related  discrepancy  procedures  as  recommended  in  Part  I,  Section  D.2.i 
the  DLSS  should  also  incorporate  performance  evaluation  of  the  discrepancy  process  1 

in  performance  measurement  procedures. 

Performance  evaluation  of  the  discrepancy  process  should  record,  summarize, 
and  report  discrepancy  information  to  enable  management  attention  to  be  directed 
toward  widespread  conditions  or  DoD  trends.  This  procedure  would  permit 
thorough,  selective  research  to  be  effectively  performed  to  identify  the  cause  of  seri¬ 
ous,  widespread  error(s)  and  cooperative,  corrective  actions  could  be  taken  at  an  ( 

earlier  time. 

MODELS  Requirement:  The  MODELS  concept  must  have  the 
capability  to  electronically  collect,  collate,  and  summarize  dis¬ 
crepancy  reports  from  all  S/A  organizations  worldwide  as  one 
element  of  performance  measurement  reporting.  These 
discrepancy  reporting  evaluation  procedures  should  be  incor¬ 
porated  into  DoD-wide  standard  performance  measures. 


B.4  Contracting. 

Contract  management  requires  measurement  of  performance  within  DoD 
contracting  offices  and  of  various  vendor  performance  characteristics.  Contracting  is 
performed  at  several  organizational  levels,  from  local  purchase  of  small  items  to 
Service  procurement  of  weapons  systems.  Measurements  are  made  for  the  levels  of 
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competition  in  contracting.  For  all  acquisitions,  especially  major  systems,  DoD 
contract  managers  must  be  able  to  evaluate  contractor  performance  with  respect  to 
delivery  milestones  and  expenditure  targets.  This  level  of  performance  measure¬ 
ment  may  require  on-line  interface  with  the  contractor’s  management  information 
system  data  bases.  Contracting  performance  measurement  must  be  available  to 
PCOs  and  ACOs  throughout  DoD.  Performance  measurement  criteria,  although 
standardized,  should  have  enough  flexibility  to  meet  changing  management 
information  needs  and  to  accommodate  differing  requirements  at  the  organizational 
level. 

The  process  of  procurement  and  contracting  should  be  monitored  by  measuring, 
at  a  minimum: 

•  Procurement  administrative  leadtime 

•  Production  leadtime 

•  Breakout  (procurement  of  spares  from  the  actual  manufacturer  vice  the 
prime  contractor  for  the  weapons  system) 

•  Competition 

•  Number  of  contracts  in  place  by  type  (requirements,  multiyear,  and 
unpriced  orders). 

These  measures  should  be  quantified  in  terms  of  both  numbers  and  value  of 
transactions.  In  addition,  management  information  is  needed  on  "pricing”  pro¬ 
grams.  That  information  should  include  the  number  and  value  of  pricing  reviews, 
challenges,  and  results  of  challenges.  Those  measurement  criteria  should  be 
incorporated  into  a  single  logistics  functions  performance  measurement  procedures 
manual  and  cross-referenced  in  the  appropriate  modernized  DLSS  functional  proce 
dures  manual. 


MODELS  Requirement:  The  DLSS  should  develop  standard 
criteria  for  measuring  procurement  and  contracting  perfor¬ 
mance.  The  MODELS  concept  must  include  procedures  to 
collect  these  standardized  performance  measurement  data  as  a 
normal  function  of  procurement  and  contract  administration 
process  information  flows. 

B.5  Interfund  Billing. 

Current  billing  procedures  are  archaic,  inefficient,  and  very  costly  to  manage. 
Every  M3LSTRIP  shipment  results  in  an  Interfund  Bill  Detail  Card  that  provides 
data  that  are  redundant  with  data  on  many  other  MILSTRIP/MILSTRAP  docu¬ 
ments.  These  large  volumes  of  billing  transactions  are  communicated  through 
AUTODIN  and  DAAS  from  the  seller  to  the  billing  office.  Images  of  these  bills  are 
stored  in  DAAS  for  1  year  to  provide  a  data  base  for  future  recovery  capability. 

These  bills  are  not  paid  until  the  buyer  has  verified  the  receipt  of  the  materiel. 
One  alternative  to  the  use  of  an  Interfund  Bill  Detail  Card  would  be  the  use  of  the 
MILSTRAP  Materiel  Receipt  Acknowledgment  Document  (MRAD)  to  electronically 
transfer  funds  from  the  buyer’s  to  the  seller’s  account.  This  action  would  eliminate 
the  need  for  a  separate  billing  transaction  to  accomplish  the  same  action. 

MODELS  Requirement:  The  MODELS  concept  should  include 
the  development  of  methods  toward  modernizing  the  capability 
to  accomplish  the  interfund  billing  procedures  without  the 
current  cost. 


B.6  Weapons  System  Management. 

Inventory  management  in  DoD  is  largely  item-  or  commodity-oriented.  Deci¬ 
sions  are  often  made  on  an  item  or  commodity  basis  without  full  consideration  of  the 
impact  they  have  on  the  readiness  of  weapons  systems.  DoD  has  long  sought  to 
develop  the  capability  to  manage  inventories  of  spare  and  repair  parts  on  a  weapons- 
system  basis  as  a  means  of  enhancing  end-item  readiness  by  focusing  management 
attention  and  resources  on  those  parts  that  directly  affect  the  readiness  of  a  weapons 
system. 


In  addition,  weapons-system  oriented  inventory  management  improves  S/A’s 
ability  to  determine  the  funding  required  to  achieve  a  prescribed  readiness  objective 
for  a  given  weapons  system  and  to  project  the  effects  of  alternative  funding  levels  on 
readiness.  Therefore,  information  is  available  to  justify  budget  submissions  for 
spare  and  repair  parts  during  departmental  and  Congressional  reviews.  In  short, 
weapons  system  management  provides  the  means  for  programming  limited  materiel 
investment  funds  more  effectively  to  achieve  a  balanced  posture  of  materiel  readi¬ 
ness  . 

Measuring  logistics  operations  performance  against  specific  weapons  system 
support  goals  represents  a  distinct  improvement  over  measuring  performance 
against  average  supply  availability  rates  (i.e.,  measures  of  the  percentage  of 
customer  demands  that  can  be  satisfied  from  stocks  on  hand).  A  high  rate  of  supply 
availability  does  not  necessarily  equate  to  high  readiness  of  a  weapons  system, 
because  if  one  critical  part  is  not  available,  the  weapons  system  may  not  be  able  to 
fulfill  its  mission. 

A  logistics  system  oriented  toward  weapons  system  management  objectives 
must  measure  logistics  operations  performance  throughout  the  weapons  system 
deployment  and  termination  phases.  Networking  of  all  applicable  logistics  data 
bases  is  critical  to  satisfying  weapons  system  support  information  requirements. 
Since  performance  measurement  objectives  are  based  on  readiness  goals  specific  to 
each  weapons  system,  flexibility  in  the  design  of  performance  measurement  criteria, 
data  used,  data  query  parameters,  and  data  information  sources  is  key  to  the  success 
of  a  weapons  system  logistics  support  performance  measurement  program. 

The  Services  and  DLA  must  develop  and  maintain  weapons  system  identifying 
data  in  their  automated  systems  for  secondary  items  identified  as  part  of  a  weapons 
system.  Weapons  system  files  identifying  item  relationships  will  be  used  to  estab¬ 
lish  the  priority  of  need  of  one  item  to  another  and  the  degree  of  criticality  of  each 


item  relative  to  its  next  higher  assembly  and,  ultimately,  to  the  end-item  or  weapons 
system.  ADP  systems  must  be  capable  of  using  item  relationship  data  in  the  require¬ 
ments  determination  process. 

Currently,  S/A  logistics  data  systems  do  not  provide  a  complete  linkage  among 
secondary  items,  higher  assemblies,  and  weapons  systems.  This  linkage  must  be 
established,  probably  within  catalog  data  files. 

Establishment  of  weapons  system  item  relationship  files  is  a  necessary  step 
toward  relating  stockage  decisions  to  the  operational  readiness  of  systems  and  will 
allow  the  most  effective  use  of  weapons  system  readiness  optimization  models.  It 
will  also  allow  the  use  of  specific  weapons  system  program  data  in  the  demand  fore¬ 
casting  process. 

Also  by  making  possible  the  identification  of  every  system  or  equipment  that  is 
dependent  upon  a  secondary  item,  the  establishment  of  complete  application  files 
will  permit  consideration  of  total  requirements  not  only  in  computing  buy/repair 
quantities  but  also  in  increasing  the  effectiveness  of  distribution  decisions,  alloca¬ 
tion  of  management  resources,  disposal  decisions,  and  such  long-range  management 
decisions  as  life-of-system  buy  determinations.  Weapons  system  management  and 
its  implications  for  the  logistics  community  are  discussed  further  in  Part  II,  Sec 
tion  C.l. 

MODELS  Requirement:  Modernized  DLSS  procedures  must 
define  a  standard  weapons  system  performance  measurement 
program,  including  standardized  weapons  system  identifica¬ 
tion  codes  in  all  applicable  transactions.  The  DLSS  procedures 
must  allow  for  multiple  weapons  system  coding  for  common- 
use  items.  The  MODELS  design  must  provide  the  automated 
capabilities  to  perform  weapons  system-oriented  performance 
measurement  of  logistics  operations.  This  must  include  access 
by  weapons  system  relationships  to  wholesale  and  retail  opera¬ 
tional  performance  measurement  data. 

In  conclusion,  DoD-standard  performance  measurement  of  logistics  operations 
are  now  very  limited.  The  only  consolidated  set  of  procedures  is  that  published  in 


MILSTEP  and  measured  against  UMMIPS  standards.  A  comprehensive  set  of 
performance  measurement  criteria  to  address  all  logistics  functions,  including 
weapons  system  defined  operations,  is  needed.  A  substantial  effort  in  this  regard  has 
already  been  completed  by  the  Spares  Program  Management  Directorate  within 
Logistics  and  Materiel  Management  (L&MM)  in  the  Office  of  the  Secretary  of 
Defense  (OSD).  However,  baseline  measurement  standards  must  still  be  developed 
for  many  of  the  criteria,  and  implementing  procedures  must  be  developed. 

MODELS  Requirement:  A  comprehensive  set  of  logistics 
operations  performance  measurements  should  be  developed 
and  implemented  through  a  DLSS  procedural  publication. 


CHAPTER  C.  ACQUISITION  FUNCTIONAL  REQUIREMENTS 


In  the  WBS,  the  Acquisition  function  is  subdivided  into  three  functional  areas: 
Primary  Item  Acquisition,  Secondary  Item  Acquisition,  and  Technical  Data  Acquisi 
tion.  Only  Secondary  Item  Acquisition  is  within  the  scope  of  this  initial  review  of 
MODELS  requirements.  The  other  two  functional  areas  should  be  considered  for 
inclusion  in  MODELS  in  the  future.  Figure  C-4  shows  the  WBS  functions  for  Acqui¬ 
sition,  and  Table  C-4  describes  those  functions. 

The  Secondary  Acquisition  process  is  decomposed  into  its  two  major  functional 
activities.  Procurement  and  Contract  Administration.  Those  activities  and  their 
DLSS/MODELS  relationships  are  discussed  below. 

C.l  Procurement  Activities. 

Procurements  are  driven  by  weapons  system,  facility,  and  other  materiel 
resource  requirements.  Requests  for  procurement  generally  flow  from  the  IM  at  the 
wholesale  level  and  vary  in  quantity  from  one  to  thousands.  The  PCO  combines  total 
requirements  for  each  commodity  and  processes  each  purchase  in  accordance  with 
the  FAR  and  DFARS.  The  PCO  determines  the  most  feasible  procurement  action. 
Those  actions  include  sealed  bidding,  negotiation  procedures,  small  purchases,  and 
imprest  fund. 

Normally,  the  IM  asks  the  PCO  to  execute  the  procurement  in  specified  quanti¬ 
ties  for  delivery  by  specified  dates.  The  PCO  is  charged  with  the  responsibilities  for 
soliciting  offers,  negotiating  contracts,  awarding  contracts,  and  terminating  con 
tracts. 

Accurate,  timely  information  is  essential  to  the  efficient  processing  of  procure¬ 
ment  actions.  In  today’s  automated  environment,  many  procurements  can  be  and 
are  initiated  automatically.  Procurements  of  fhis  type  are  dependent  on  the 
availability  of  automated  listings  of  prior  bidders  and  their  previous  prices. 


*-■  «->  |J 


1  Jt' «U  A  j**  ■<*  j1*  ■  »*  *-*  ■ 


FIGURE  C-4.  SECONDARY  ITEM  ACQUISITION  FUNCTIONS 
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TABLE  C-4.  DESCRIPTIONS:  ACQUISITION  FUNCTIONS 


FUNCTIONS 

DESCRIPTIONS 

2.0 

Acquisition 

The  process  of  obtaining  supplies  or  services  by  contract  through  purchase  or  lease, 
regardless  of  whether  the  quantities  to  be  acquired  are  already  in  being  or  must  be 
created,  developed,  or  demonstrated  and  evaluated.  Acquisition  begins  when  require¬ 
ments  are  established  and  functional  specifications  are  documented  It  includes  selection 
of  sources,  solicitation,  award  of  contract,  funding,  performance  monitoring,  contract 
administration,  and  technical  and  management  functions  that  are  directly  related  to 
satisfying  requirements  by  contract.  This  includes  preparation  of  technical  data  specifica¬ 
tions  for  materiel  contracts. 

Acquisition  of  primary  items  is  concerned  with  end  items  and  replacement  assemblies  of 
such  major  importance  that  detailed  analysis  and  review  are  required  of  all  factors 
affecting  their  supply  and  demand.  Primary  items  are  normally  designated  on  the  basis  of 
essentiality  for  combat  or  training,  high  financial  value,  difficulty  of  procurement  or 
production,  or  criticality  of  basic  materiels  or  components 


2  2 

Secondary  Item 
Acquisition 

The  process  of  obtaining  equipment  and  supplies  not  identified  as  a  primary  item 
Secondary  items  include  reparable  components,  subsystems  and  assemblies,  consumable 
repair  parts,  bulk  items  and  material,  and  expendable  minor  end  items 

2.2.1 

Procurement 

The  process  of  obtaining  personnel,  services,  supplies,  and  equipment  from  the  private 
sector  through  purchase  order,  contract,  or  other  obligating  documents 

Policies,  procedures,  and  practices  are  established  requiring  the  Government  to  acquire 
goods,  services,  and  facilities  of  the  requisite  quality  and  within  the  time  needed  at  the 
lowest  reasonable  cost  using  competitive  bidding  to  the  maximum  extent  possible  This 
formulation  takes  into  account  the  fact  that  present  procurement  laws  require 
consideration  of  not  only  cost  but  other  factors,  such  as  quality  and  urgency,  in  the  award 
of  procurement  contracts  Effective  formal  advertising  relies  wholly  upon  competitive 
pressure  for  reasonable  prices 


Negotiation  means  contracting  through  the  use  of  either  competitive  or  other-than- 
competitive  proposals  and  discussions  Any  contract  awarded  without  using  sealed  bidding 
procedures  is  a  negotiated  contract  Negotiation  is  a  procedure  that  includes  the  receipt  of 
proposals  from  offerors,  permits  bargaining,  and  usually  affords  offerors  an  opportunity  to 
revise  their  offers  before  award  of  a  contract  Bargaining  -  in  the  sense  of  discussion,  per¬ 
suasion.  alteration  of  initial  assumptions  and  positions,  and  give-and-take  -  may  apply  to 
price,  schedule,  technical  requirements,  type  of  contract,  and  other  terms  of  a  proposed 
contract 


2  2  1  3  |  The  award  of  a  contractual  obligation  for  services,  equipment,  or  supplies  to  a  commercial 

vendor  Usually  a  formal  document  is  signed  by  the  Government  and  the  contractor  s 
official  representative  for  a  specified  quantity  to  be  delivered  at  a  specific  location  by  a 
certain  date 


2  2  1  2 

Negotiation 


2  2.1  1 

Solicitation 
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TA8LEC-4.  DESCRIPTIONS:  ACQUISITION  FUNCTIONS  (CONTINUED 


FUNCTIONS 

DESCRIPTIONS 

2  2  2 

Contract 

Administration 

Contract  administration  comprises  all  the  actions  that  the  Government  must  take  with 
respect  to  the  contractor  until  the  material  or  service  has  been  delivered,  accepted,  and  paid 
for,  and  the  contract  closed  out  These  actions  range  from  production  surveillance  through 
inspection,  quality  assurance,  and  expediting  on  the  one  hand  and  allowance  of  costs, 
change-order  pricing,  termination  settlements,  property  management,  and  payment  on  the 
other  The  five  major  categories  of  functions  performed  include  (1)  provision  of  broad 
supporting  services  to  the  procuring  agency.  (2)  enforcement  of  contract  provisions,  (3)  con¬ 
trol  of  performance  costs  and  product  quality,  (4)  performance  of  liaison  and  coordination 
services  between  contractor  and  procuring  agency,  and  (5)  collection  and  evaluation  of  data 
relating  to  contractor  performance  Management  during  the  performance  phase  of  a  con¬ 
tract  is  the  primary  responsibility  of  the  contract  administration  office 

2  2  2  1 

Maintain  Contract 
Administration 

Data  Base 

The  process  of  maintaining  a  comprehensive  data  base  of  contracts  and  contract  data  The 
data  base  should  include  standard  clauses  and  data  elements  necessary  to  the  administration 
and,  when  applicable,  payment  of  the  contract  It  should  contain  all  related  contract 
performance  measurement  and  qualitative  remarks  The  data  base  should  be  capable  of 
accepting  and  issuing  applicable  MILSCAP  transactions 

2  2  2  2 

Technical 

Administration 

Among  the  continuing  functions  of  contract  administration,  the  most  important  are 
surveillance  of  the  contractor  s  progress  toward  completion  and  maintenance  of  a  constant 
flow  of  information  to  the  procuring  activity  on  the  status  of  contracts  In  most  contracts 
where  progress  information  is  necessary,  the  two  factors  of  primary  interest  are  actual 
progress  toward  completing  the  work  and  financial  status  of  the  contract  The  extent  and 
degree  of  monitoring  required  on  a  particular  contract  depend  on  the  size,  complexity,  and 
urgency  of  the  project. 

2  2  2  3 

Contract  Financial 
Administration 

A  ma|Or  instrument  for  protecting  the  Government's  interest  is  its  contract  auditing 
organization  Contract  audits  are  carried  out  primarily  to  (1)  aid  in  pricing,  and  (2)  review 
and  recommend  to  ACOs  the  action  they  should  take  on  vouchers  submitted  for 
reimbursement  under  cost-type  contracts  Contract  audit  reports  are  normally  required  on 
all  proposed  negotiated  procurements  of  more  than  $100,000  The  audit  report  is  submitted 
to  the  ACO  who  consolidates  and  evaluates  the  findings  of  the  pricing  team  for  submittal  to 
the  procuring  officer 

2  2  2  4 

Quality  Assurance 

Quality  assurance  means  monitoring  product  quality  during  production,  upon  acceptance, 
and  in  use  to  prevent  or  detea  defects  or  nonconforming  conditions  that  would  limit  the 
ability  of  the  product  to  fulfill  its  purpose  Where  the  item  being  bought  is  commercial, 
uncomplicated,  and  not  critical,  total  reliance  is  often  placed  on  the  contractor's  internal 
quality  control  program  In  contracts  for  complex,  critical  military  items  on  the  other  hand, 
the  contractor  may  be  required  to  establish  and  maintain  a  program  that  meets  detailed 
Government  specifications 

2  3 

Technical  Data 
Acquisition 

1 _ 

The  activities  relating  to  the  policies  and  procedures  used  to  obtain  needed  tecnmcal  data  for 
maintenance  and  repair,  spare  parts  procurement,  and  inventory  management  For  major 
end  items  the  technical  data  are  usually  acquired  from  the  R&D  contractor  as  one  product  in 
the  total  set  of  contractual  deliverables 
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performance  characteristics,  order  and  contract  characteristics  (minimum  order 
quantities,  economic  order  quantities,  etc.),  average  leadtime  information,  and 
similar  procurement-type  data.  From  the  Government’s  viewpoint,  the  automated 
system  needs  minimum  and  maximum  order  quantity,  demand  projections, 
acceptable  substitutes,  required  delivery  dates  (RDDs),  delivery  locations,  and  simi¬ 
lar  contractual  terms  and  conditions  to  stimulate  competition  and  complete 
negotiations. 

Large  procurements  are  conducted  manually.  Most  procurements  of  $10,000  or 
more  are  announced  in  the  Commerce  Business  Daily.  Government  specifications 
and  requirements  are  described  in  formal  solicitations  (sealed  bidding  and/or 
contracting  by  negotiations).  A  comprehensive  evaluation,  with  subsequent 
requests/responses  for  clarification,  when  applicable,  precede  the  final  contract 
award.  This  process  is  often  a  lengthy  one,  taking  from  6  months  to  as  long  as 
36  months  in  extreme  cases  for  major  end-items  requiring  an  operational  demon 
stration  as  part  of  the  final  negotiation  process. 

MODELS  Requirement:  The  modernized  DLSS  procedures 
should  encompass  standard  procurement  functions,  contract 
modifications,  and  related  inter-S/A  information  exchange 
requirements. 

C.2  Contract  Administration  Activities. 

Upon  award  of  the  procurement,  a  contract  is  issued;  it  must  be  administered 
through  completion,  either  delivery  of  the  commodity,  performance  of  the  service,  or 
termination  of  the  contract.  The  PCO  either  administers  the  contract  with  his/her 
own  resources  or  passes  responsibility  for  administration  to  an  ACO.  Contract  data 
is  critical  to  effective  performance  of  contract  activities  and  functions.  Each  PCO, 
ACO,  and  contractor  maintains  some  form  of  contract  management  data  base. 
Contracting  data  should  be  available  in  an  on-line  data  base  in  a  form  to  facilitate 
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variable  queries.  The  ACO/PCO  information  needed  in  this  data  base  includes: 


•  Contract  and  contract  modification  information 

•  Pertinent  Quality  Deficiency  Reports  (QDRs)  and  Reports  of  Discrepancy 
(RODs)  data,  to  be  used  for  management  review  during  contract  adminis¬ 
tration 

•  Shipment  information 

•  Revised  delivery  information 

•  Contractor  invoice  and  payment  information 

•  Audit  trails  of  all  transactions 

•  Contract  historical  files. 

During  administration,  the  ACO  informs  the  PCO  routinely  about  the  status  of  the 
contract.  The  ACO  is  charged  with  responsibility  for  (1)  maintaining  contract 
administration  data;  (2)  carrying  out  such  technical  administration  functions  as 
receiving  and  transmitting  shipment  performance  information,  destination  accep¬ 
tance  information,  revised  delivery  forecast  information,  and  contract  completion 
status  reports;  (3)  ensuring  that  Defense  Contract  Administration  Service  Region 
(DCASR)  conducts  contract  financial  administration;  (4)  performing  quality  assur 
ance  reviews;  and  (5)  facilitating  DoD-to-vendor  data  interchange. 

C.2.a  MJLSCAP  Transactions. 

MILSCAP  transactions  are  currently  used  to  a  very  limited  extent  to  transmit 
the  standard  contract  data  elements  required  for  standard  contract  procurement  and 
administration  procedures.  Today’s  transactions  are  fixed  in  length  and  transmit  a 
minimum  amount  of  pertinent  data. 
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MODELS  Requirement:  MODELS  acquisition  function  trans 
action  formats  must  be  variable  in  length  to  accommodate  ad 
S/A  contract  data  exchange  requirements.  All  procurement 
and  contract-related  information  should  be  available  electron 
ically. 

C.2.b  Maintain  Contract  Administration  Data  Base. 

Contract  data  from  the  PCO  are  maintained  in  the  ACO’s  data  base  for  contract 
administration.  Contract  abstract  data  establish  the  contract  administration  data 
base,  which  must  be  designed  to  help  the  ACO  manage  the  following: 

•  Master  contract  file  records 

•  Receipt  of  contract  major  event  status 

•  Property  administration 

•  Quality  assurance 

•  Production 

•  Transportation 

•  Management  statistics. 

DoD  and  its  contractors  should,  when  practical,  have  on-line  capability  for  a 
designated  level  of  direct  interface  with  each  other’s  contract  data  bases.  This 
interface  should  include  a  limited-access  query  capability  into  the  vendor’s  manage¬ 
ment  data  bases  and  vice  versa.  Access  to  those  data  bases  will,  in  all  cases,  be  as 
determined  by  agreement  with  the  contractor.  The  scope  of  data  base  access  will  be 
limited  through  software  security  controls. 

C.2.c  Technical  Administration. 

Technical  administration  is  the  heart  of  the  contract  transaction  environment; 
in  other  words,  most  of  the  data  exchanged  between  S/As  will  stem  from  the 
technical  administration  function.  These  transactions  include,  but  are  not  limited 
to,  four  basic  families:  (1)  shipment  performance  notices  (SPNs),  (2)  destination 
acceptance  reports  (DARs),  (3)  revised  delivery  forecasts  (RDFs),  and  (4)  contract 


completion  status.  The  SPN,  the  means  of  providing  timely  notification  of  shipment 
of  materiel  or  completion  of  a  service  by  a  contractor,  should  provide  information  for 
updating  asset  requirement  status,  pipeline  status,  MILSTRIP  status,  and  customer 
billing  and  payment.  The  DAR  should  serve  to  notify  the  paying  office  that  the 
customer  has  accepted  the  materiel  and  the  contractor  should  be  paid.  Destination 
acceptance  should  also  serve  „o  notify  payment  offices  to  post  customer  financial 
accounts  accordingly.  The  RDF  should  notify  applicable  PCO  activities  about  antici¬ 
pated  or  actual  deviations  from  the  original  contract  delivery  schedule.  It  should 
provide  a  new  forecast  delivery  date  and  the  reason  for  revising  the  original  date. 
The  contract  completion  status  allows  for  reporting  of: 

•  Status  of  closed  contracts  when  performance  has  been  completed 

•  Major  events  leading  to  the  closing  of  contract  files 

•  Unclosed  contract  statements  when  DFARS  contract  close-out  dates  are  not 
met 

•  Final  notification  of  contract  close-out. 

With  respect  to  these  four  families  of  transactions  —  SPN,  DAR,  RDF,  and 
reports  of  contract  completion  —  data  must  flow  freely  among  all  potential  users. 
Contract  administration  status  affects  management  decisions  d.rectly  in  supply, 
transportation,  and  maintenance.  The  data  should  be  available  by  part  number  and 
national  stock  number  (NSN)  to  provide  a  broad  view  of  materiel  on  order. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
access  to  contract  data  via  various  data  elements  and  also 
establish  and  maintain  relationships  among  data  elements 
through  a  well-designed  data  architecture. 

C.2.d  Contract  Financial  Administration. 

This  function  entails  preparation  of  detailed  payment  or  collection  data.  The 
data  should  then  be  transmitted  automatically  to  the  appropriate  finance  office  for 
posting  to  the  applicable  contractors.  As  accounts  are  paid,  the  customer’s 


accountable  activities  are  automatically  notified.  That  notification  includes 
identification  of  any  payment  variances  from  amount  originally  committed  to  the 
customer. 


C.2.e  Quality  Assurance. 

Quality  assurance  parameters  must  be  identified,  documented,  and  measured. 
As  a  result  of  continued  quality  evaluations,  contractor  deficiency  reports  (CDRs) 
are  prepared  and  presented  to  the  contractor  for  resolution. 

MODELS  Requirement:  CDRs  should  become  a  part  of  ACO/ 

PCO  data  bases  and  should  be  available  on-line. 

C.3  Technical  Data  Acquisition. 

Technical  data  acquisition  is  becoming  increasingly  important  as  a  major 
function  of  the  procurement  process.  It  is  critical  to  effective  maintenance  of 
weapons  systems  at  all  levels  and  fosters  increased  competition  after  initial 
provisioning.  Although  acquisition  of  technical  data  is  not  addressed  in  current 
MODELS  design  efforts,  the  MODELS  project  recognizes  its  importance  and  the 
need  for  eventual  inclusion  in  DLSS  procedures.  OSD  is  now  sponsoring  an  exten¬ 
sive  project  to  address  technical  data  acquisition  and  automation.  The  MODELS 
team  is  maintaining  a  continuing  awareness  of  developments  and  recommendations 
of  the  Computer-Aided  Logistics  Support  (CALS)  OSD  project.  CALS  recommenda¬ 
tions,  policies,  procedures,  and  information  exchange  protocols  will  be  incorporated 
into  MODELS  efforts  as  they  are  documented  and  approved.  Standard  information 
communication  transactions,  including  the  ability  to  transmit  drawings  and  photo¬ 
graphs,  will  be  required  in  future  stages  of  the  MODELS  implementation.  A 
proposed  MODELS  functional  area  coverage  for  future  consideration  is  provided  in 
Figure  C-5. 


FIGURE  C-5.  TECHNICAL  DATA  ACQUISITION  FUNCTIONS 
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MODELS  Requirement:  The  MODELS  effort  should  continue 
to  closely  monitor  CALS  developments  and  information 
exchange  protocols  and  procedures.  As  standards  are 
developed  by  the  OSD-CALS  Group  for  technical  data  acquisi¬ 
tion  and  distribution  procedures  and  communications  inter¬ 
faces,  these  standards  should  be  published  as  part  of  the 
modernized  DLSS  technical  data  functions  discussed  here  and 
in  Part  I,  Section  D.3. 

As  previously  described  in  Table  C-4,  technical  data  acquisition  encompasses 
the  activities  related  to  the  policies  and  procedures  used  to  acquire  needed  technical 
data  for  maintenance,  spare  parts  replenishment  procurement,  and  inventory 
management.  Most  technical  data  for  major  end  items  are  acquired  from  the  R&D 
contractor  during  the  initial  provisioning  process.  All  parts  designated  for  the 
initial  allowance  list  are  coded  with  a  vendor-unique  part  number  and  assigned  an 
NSN  by  the  Defense  Integrated  Data  System  (DIDS). 
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During  this  initial  provisioning  process,  issues  of  data  rights  must  be  carefully 
reviewed  and  evaluated  to  ensure  future  competition  in  the  procurement  of  replen¬ 
ishment  spare  parts.  Data  rights  involve  the  determination  by  the  Government  of 
who  rightfully  owns  the  data.  Parts  designed  and  developed  by  the  contractor  with 
company  independent  R&D  funds  are  designated  as  contractor-owned,  and 
associated  technical  data  may  be  distinguished  by  proprietary  data  markings.  Parts 
developed  with  government  funds  or  available  from  other  commercial  sources  are 
open  stock,  and  technical  data  are,  therefore,  nonproprietary. 

Replenishment  spare  parts  for  which  technical  data  are  inadequate  or  marked 
proprietary  are  often  subjected  to  reverse  engineering.  That  function  is  the  set  of 
activities  relating  to  the  application  of  engineering  techniques  to  existing  spare 
parts  to  determine  a  more  cost-effective  design/production  methodology  and  to 
develop  adequate  technical  data  specifications  that  will  make  competitive  procure¬ 
ment  more  likely. 

Engineering  and  design  activities  include  the  evaluation  and  analysis  of  spare 
parts  to  determine  the  level  of  technical  data  requirements.  Because  major  end 
items  are  constantly  being  changed  and  improved  as  they  are  used  in  operational 
environments,  configuration  management  of  technical  data  is  a  critical  factor  in 
both  maintenance  and  supply  operations. 

Configuration  management  is  the  set  of  activities  relating  to  the  effective 
management  of  systems  configuration  data.  For  the  maintenance  engineer  such 
technical  data  are  vital  to  ensure  that  correct  parts  are  used  in  repair  or  replace 
ment.  To  the  supply  officer,  the  data  are  vital  to  ensure  that  correct  parts  are 
ordered  and  in  stock  for  maintenance.  As  parts  change  over  time,  timely  config 
uration  management  change  notices  allow  supply  operations  to  identify  parts  for 
excessing  at  the  earliest  possible  time. 


V  V  *- 
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The  final  function  addressed  in  Figure  C-5  is  technical  data  maintenance.  It 
includes  activities  related  to  development  and  execution  of  policies,  systems,  and 
procedures  for  the  storage,  retrieval,  and  exchange  of  technical  data  between  S/As 
responsible  for  maintenance  and  operation  of  the  end  item  or  support  equipment. 


CHAPTER  D.  SUPPLY  FUNCTIONAL  REQUIREMENTS 


The  major  functions  of  supply,  as  illustrated  in  the  WBS  shown  in  Figure  D-6, 


encompass: 

•  Retail  operations 

•  Wholesale  inventory  management 

•  Technical  data  management 

•  Wholesale  storage. 

Most  DLSS  functional  requirements,  both  existing  and  proposed,  fall  into  the 
supply  operations  area.  The  current  DLSS  encompass  wholesale  inventory  manage¬ 
ment,  wholesale  storage,  retail  requisitioning,  and  wholesale  requisition  processing. 
The  integrated  MODELS  approach  envisions  more  complete  coverage  of  these  areas, 
with  additional  functions  added  to  the  DLSS  concept.  Each  of  the  third-tier  WBS 
supply  functions  is  discussed  in  detail  below. 

D.l  Retail  Requisitioning. 

Most  S/A  retail-level  systems  are  based  on  or  parallel  the  existing  DLSS.  The 
scope  of  proposed  DLSS  coverage,  within  the  MODELS  framework,  for  retail  requisi¬ 
tioning  is  shown  in  Figure  D-7.  Retail  operations  WBS  functions  are  described  in 
Table  D-5.  Under  the  MODELS  concept,  retail  transactions  using  variable-field/ 
variable-length  transaction  formats  could  easily  cross  S/A  lines.  Intermediate  retail 
supply  centers  [e.g.,  Naval  Supply  Centers  (NSCs)]  and  base/unit-level  direct-user 
issue-supply  facilities  could  use  common  elements  for  local  issue  and  internal 
processing. 

A  data  base  management  system  (DBMS)  data  architecture  based  on  a  stan 
dard  data  model  would  allow  local  variations  and  unique  data  elements  to  be  super 
imposed  on  the  DLSS  superstructure.  This  type  of  operation  would  preserve  the 
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FIGURE  D-6.  SUPPLY  FUNCTIONS 
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FIGURE  0-7.  SUPPLY:  RETAIL  OPERATIONS  FUNCTIONS 
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TABLE  D-5.  DESCRIPTIONS:  SUPPLY/RETAIL  OPERATIONS  FUNCTIONS 


FUNCTIONS 

DESCRIPTIONS 

3  0 

Supply 

The  function  of  supply  is  to  provide  end  items,  equipment,  and  repair  and  replacement  parts  to 
operational  and  support  units  on  an  as-requested  basis  The  supply  process  begins  with  a  request 
for  equipment  or  materiel,  usually  by  a  retail-level  unit  using  a  requisition  document  if  the 
requested  item(s)  is  not  available  at  the  retail  unit,  the  requisition  is  processed  through  the  supply 
system  to  the  wholesale  inventory  management  function  During  the  requisitioning  process,  tech¬ 
nical  data  may  be  required  for  initial  item(s)  identification  or  subsequent  determination  of 
acceptable  substitutes  If  the  item(s)  are  physically  available  in  the  DoD  supply  system,  the  appro¬ 
priate  wholesale  storage  facility  is  requested  to  process  the  item(s)  for  shipment  to  the  requisi- 
tioner.  Thus,  the  supply  function  includes:  (1)  retail  operations,  (2)  wholesale  inventory  manage¬ 
ment,  (3)  technical  data  management,  and  (4)  wholesale  storage  as  major  subfunctions  for  this 
MODELS  analysis 

3  1 

Retail 

Operations 

The  supply  operations  of  retail-level  installations  have  two  bases  nondemand  based  stocks 
required  to  ensure  materiel  readiness  of  supported  units  and  stockage  criteria  based  on  demand 
and/or  item  essentiality.  Exceptions  are  made  for  stocks  relating  to  certain  medical  and  mission 
supplies  and  for  supplies  authorized  by  official  authorization  documents  The  ability  of  retail-level 
customers  to  operate  effectively  is  directly  related  to  the  responsiveness  of  the  wholesale-level 
supply  activities 

3  1  1 

Retail 

Requisitioning 

Stockage  of  supplies  at  retail-level  installations  is  based  primarily  upon  demand  or,  if  approved  as 
mission  essential,  for  war  reserve  Requisitioning  objectives  depend  upon  demand  and  upon  the 
leadtime  required  to  place  goods  on  the  shelves 

3  1.1.1 

Requisitions 

Four  types  of  procedures  are  associated  with  submission  of  a  request  for  equipment  or  materiel:  (1) 
the  requisition  is  the  basic  request  from  the  retail  (or  user)  level  to  the  wholesale  level;  (2)  the 
requisition  can  be  modified  after  it  is  submitted  to  the  wholesale  source  through  a  "modifier";  (3) 

To  cancel  the  entire  initial  requisition,  a  cancellation  notice  is  issued;  and  (4)  a  requirements 
information  notice  is  used  to  notify  the  wholesale  source  of  forthcoming/projected  retail-level 
requirements. 

3  1  1  2 

Pipeline  Status 
(Inquiry  and 
Response) 

The  requisition  status  is  provided  to  the  retail  requisitioner  from  the  wholesale  source  of  supply  or 
the  depot  as  appropriate  When  a  requisition  is  being  satisfied  directly  from  vendor  procurement, 
the  contract  administrator  is  responsible  for  regularly  notifying  the  item  manager  who  passes  the 
information  along  to  the  requisitioner(s).  The  retail-level  requisitioner  is  also  notified  of 
transportation  shipment  actions. 

3  113 

Receipt  Take-Up 
and 

Ack  nowledgment 

Pre-positioning  of  due-m  is  the  process  by  which  the  requisition  due-in  status  is  posted  to  the 
requisition  record  within  the  requisition  data  base  The  retail  levei  notifies  the  wholesale  level  that 
it  has  received  the  requisitioned  property  The  receipt  acknowledgment  process  is  crucial  to 
accurate  pipeline  measurement 

3  114 

Report  of 
Discrepancy 

Three  basic  types  of  discrepancies  are  reported  within  military  logistics  retail  operations  from  the 
retail  level  to  the  wholesale  level:  (1)  supply-type  discrepancies,  (2)  transportation  discrepancies, 
and  (3)  quality  deficiencies 

3  115 

Excessmg 

The  general  procedure  is  that  the  retail  level  notifies  the  IM  at  the  wholesale  level  that  property  is 
available  at  the  retail  level  for  disposition  The  IM  responds  by  directing  disposition  of  the  property 
Retail-level  actions  are  taken  in  response  to  these  property  disposition  instructions  Retail-level 
actions  are  also  taken  on  the  basis  of  retail-level  decisions  for  property  not  managed  by  the 
wholesale  level  The  property  is  made  available  in  accordance  with  applicable  DoD  instructions 

3  116 

Shipments 

Retail  level  shipments  include  redistribution  and  materiel  returns.  Redistribution  is  the  process  by 
which  property  is  shipped  to  an  authorized  user  as  determined  by  wholesale  inventory 
management  Property  shipped  from  the  retail  level  to  the  wholesale  level,  as  directed  by  the 
wholesale  inventory  management,  is  categorized  as  a  return  By  shipment  notification,  the 
consignor  informs  the  receiver  that  the  shipment  has  been  made;  for  redistributions  and  returns 
the  ICP  would  also  be  notified 

document  control  number  from  the  end-user  to  the  wholesale  source  and  would 
standardize  the  initial  requisition  date  for  control  and  meaningful  comparison  of 
performance  (i.e.,  the  date  the  demand-user  generates  the  requisition,  rather  than 
the  date  the  supply  center  generates  the  demand-requisition,  because  the  latter  date 
varies  among  S/As). 

A  standard  DLSS  document  identification  and  control  number  is  essential,  but 
incorporating  S/A  supplemental  controls  into  a  variable-field  requisition  would  be 
feasible. 


D.l.a  Requisitions. 

Under  the  MODELS  concept,  the  requisitioner  at  intermediate  retail  levels 
[i.e.,  NSCs  or  Air  Force  base  supply]  should  be  allowed  direct  access  via  remote 
terminal  to  wholesale-source  R&M  data  bases  for  inquiries  and  asset  status.  That 
access  is  now  available  to  a  limited  set  of  retail  users  connected  to  the  Defense 
Logistics  Agency  Telecommunications  Network,  (DLANET).  However,  inter-S/A 
standards  for  both  access  and  inquiry  functions  to  all  ICPs  should  be  standardized  for 
retail  users.  Interactive  inquiry  could  also  reduce  the  need  for  massive,  redundant, 
Service-maintained  logistics  data  files  and  could  reduce  the  requirement  for 
broadcasting  routine  status.  The  latter  issue  is  discussed  in  more  detail  in  Part  H, 
Section  B.3. 

Standardization  of  requisitioning  procedures  and  transactions  at  retail  levels  is 
needed  to  promote  intra-  and  inter-Service  redistribution  of  both  critical  and  excess 
assets.  Enhanced  retail  interfaces  with  other  logistics  components  will  lead  to 
increased  visibility  of  retail  assets,  promoting  redistribution  of  excess  materiel  and 
encouraging  the  sharing  of  scarce  items. 


Retail-users,  whether  supply  or  maintenance  managers,  should  be  able  to 
initiate  requisitions  and  related  transactions,  using  on-line,  full-screen  displays 
with  local  editing.  This  use  should  include  such  follow-up  actions  as  modifiers  and 


cancellations.  This  interactive  capability  should  also  provide  supply  sources  with 
requirements  and  demand  information.  MILSTRIP  and  MILSTRAP  are  prescribed 
but  not  implemented  uniformly  at  the  retail-user  level. 

End-user  interfaces  must  be  designed  to  ease  access  to  the  supply  system  by 
maintenance  personnel,  configuration  control  personnel,  and  weapons  system  opera¬ 
tions  planners,  as  well  as  retail  supply  personnel.  The  MODELS  concept  should 
review  the  feasibility  of  permitting  direct  access  to  all  S/A  wholesale  suppliers, 
especially  DLA  and  GSA.  Considerations  for  direct-access,  interactive  capability 
should  include  monitoring  of  high-priority,  not-mission-capable-supply  require¬ 
ments,  and  more  accurate  and  timely  notice  of  the  effects  on  weapons  systems. 

A  critical  need  exists  for  supply  retail  systems  to  develop  an  effective  retail- 
wholesale  interface  to  relate  retail  issues  to  replenishment  demands  on  the  whole¬ 
sale  system.  Development  of  this  concept  requires  some  standardization  in  the 
design  of  retail/intermediate-level  data  bases  to  support  end-user  requisition  control 
files.  The  wholesale  system  could  then  be  restructured  to  separate  retail  issue  and 
stock  replenishment  demand  processing,  thereby  providing  a  better  level  of  supply 
support  for  retail  demand  requisitions. 

MODELS  Requirement:  Retail  requisitioning  should  be  DLSS 
compatible  throughout  the  S/A  logistics  community.  DLSS 
procedures  should  standardize  the  requisitioning  transaction 
to  accommodate  retail-level  end-user  requirements. 


D.l.b  Pipeline  Status  —  Inquiry  and  Response. 

The  requisition  status  is  provided  to  the  retail  requisitioner  from  the  wholesale 
source  of  supply  or  the  depot,  as  appropriate.  When  a  requisition  is  being  satisfied 
directly  from  vendor  procurement,  the  contract  administrator  is  responsible  for 
regularly  notifying  the  item  manager  of  its  status,  and  he/she  should  pass  the 
updated  and/or  revised  information  along  to  the  requisitioner(s).  The  retail-level 
requisitioner  is  also  notified  of  each  transportation  shipment  action.  MODELS  must 


provide  customers  and  command  elements  with  the  capability  to  track  requirements 
and  materiel  through  the  logistics  pipeline.  This  inquiry  capability  should  include: 


•  Supply  source  status 

•  Vendor  status 

•  Depot  status  —  hold,  denial,  shipment 

•  Transportation  processing  status  —  reason  for  delay,  shipping  information. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
retail  users  with  direct,  on-line  access  to  retail  supply  echelons 
within  their  supply  issue  hierarchy  and  then  to  the  wholesale 
logistics  systems  for  inquiries  about  stock  availability,  identi 
fication  of  retail-issue  requisition  demand  and  shipment 
action. 


D.l.c  Receipt  Take-Up  and  Acknowledgment. 

Pre-positioning  of  due-ins  is  the  process  by  which  due-in  status  of  the  requisi¬ 
tion  is  communicated  to  the  requisitioner.  The  retail  level  in  turn  notifies  the  whole 
sale  level  when  it  has  received  the  requisitioned  item.  This  receipt  acknowledgment 
process  is  crucial  to  accurate  pipeline  measurements.  The  DLSS  functional  moderni¬ 
zation  should  incorporate  standard  procedures  for  retail  receipt  take  up  and 
acknowledgment  in  a  closed-loop  system,  to  improve  the  accountability  and  trace- 
ability  of  materiel.  This  process  is  now  being  considered  under  the  umbrella  of  the 
Materiel  Receipt  Acknowledgment  and  Supply  Discrepancy  Reporting  System 
(MRASDRS).  Standardized  implementation  of  these  procedures  would  encourage 
reliance  on  retail  requisition  records  to  establish  due-ins. 

MODELS  Requirement:  The  MODELS  concept  must  recognize 
the  usefulness  of  bar  coding  for  the  receipt  take-up  and 
acknowledgment  process  and  must  include  DLSS  procedures 
for  accessing  due-in  posted  data,  using  bar-coding  techniques, 
with  automated  receipt  posting  and  reporting. 


D.l.d  Discrepancy  Reporting  and  Processin 

The  three  basic  types  of  discrepancies  that  are  reported  from  the  retail  level  to 
the  wholesale  level  are  supply-type  discrepancies,  transportation  discrepancies,  and 
quality  deficiencies.  Automated  retail  discrepancy  reporting,  with  a  tie-in  to  receipt 
processing,  would  provide  a  closed-loop  system  and  materiel  accountability,  incorpo¬ 
rating  the  MRASDRS  concept.  DLSS  standard  procedures  for  discrepancy  reporting 
should  not  be  limited  to  supply  discrepancies;  rather,  they  should  be  an  integrated 
system  that  also  includes  transportation  discrepancies  and  quality  deficiencies. 

MODELS  Requirement:  The  MODELS  implementation 
should  encourage  automating  all  types  of  discrepancy/defi¬ 
ciency  recordkeeping  and  propose  procedures  for  automated 
response  and  disposition  instruction  processing,  in  accordance 
with  integrated  standards  published  in  modernized  DLSS 
procedures. 

D.l.e  Excess  Reporting  and  Reutilization. 

Customers  may  report  excess  materiel  to  either  the  retail  or  wholesale  support 
activity.  In  the  DRMS,  rapid,  accurate  identification  and  materiel  accountability 
are  major  concerns.  On-line,  interactive  capability  for  DRMS  functions  should 
dramatically  improve: 

•  In-service  reutilization 

•  Reporting  to  item  managers 

•  IM-directed  disposition  actions 

•  Retail- or  user-level  disposition. 

Development  of  an  on-line  network  for  improving  R&M  functions  is  already 
underway  through  development  of  the  Defense  Reutilization  and  Marketing  Service 
Automated  Information  System  (DAISY).  The  DAISY  capability  should  be  inter 
faced  into  the  MODELS  system  concept  design. 


MODELS  Requirement:  The  modernized,  expanded  DLSS 
should  standardize  processing  of  materiel  and  equipment  to 
DRMO’s,  including  all  types  of  local  turn-ins.  The  automated 
processing  of  materiel  to  R&M  functions,  even  for  local  turn- 
ins,  should  be  interfaced  with  MODELS  implementation. 

D.l.f  Shipments. 

Several  types  of  shipments  occur  at  the  retail  level.  Redistribution  is  the 
process  by  which  property  is  shipped  by  the  retail  organization  to  another  authorized 
user,  as  determined  by  wholesale  inventory  management.  Property  shipped  from 
the  retail  level  to  the  wholesale  level,  as  directed  by  wholesale  inventory  manage¬ 
ment,  is  categorized  as  a  return.  By  shipment  notification,  the  consignor  informs  the 
receiver  that  the  shipment  has  been  made.  The  notification  may  also  be  sent  to 
interested  third  parties.  DLSS  instructions  need  to  incorporate  information 
interchange  procedures  currently  written  in  the  MTMR  and  to  utilize  and  develop 
standard  data  interfaces  to  commercial  applications  for  Electronic  Business  Data 
Interchange  (EBDI).  Return  and  redistribution  procedures  —  including  redistribu¬ 
tion  documentation,  returns  documentation,  and  shipment  notifications  —  also  need 
to  be  standardized. 

MODELS  Requirement:  Procedures  for  all  retail  shipment 
preparation  and  documentation  should  be  incorporated  into 
the  modernized  DLSS. 

D.l.g  Other  Retail  Operations  Functions. 

The  remaining  four  functions  displayed  in  dashed  boxes  in  the  retail  operations 
WBS  diagram  (Figure  D-7)  should  eventually  be  included  in  the  DLSS  for  develop¬ 
ment  and  publication  of  standardized  procedures.  However,  since  a  great  many 
issues  remain  to  be  resolved  in  each  of  those  areas,  their  incorporation  should  be 
postponed  until  higher-priority  functional  areas  are  implemented  and  fully  accepted 
throughout  the  S/A  logistics  environment. 


D.2  Wholesale  Inventory  Management. 

The  DLSS  should  encompass  the  full  spectrum  of  information  preparation  and 
exchange  requirements  for  wholesale  inventory  management  functions  illustrated 
in  Figure  D-8  and  described  in  Table  D-6. 

D.2.a  Requirements  Computation  and  Acquisition. 

Several  DLSS  procedures  already  provide  some  data  for  requirements  compu¬ 
tations  [MILSTRIP  reports  demand  codes;  MILSTRAP  specifies  reporting  of  Logis¬ 
tics  Assets  Support  Estimates  (LASEs)  and  Special  Program  Requirements  (SPRs)]. 
The  MODELS  concept  should  include  standards  for  analysis  of  demand  and  presen¬ 
tation  of  requirements  data. 

The  Services  ensure  that  allowance  computations  for  initial  provisioning  are 
consistent  with  the  computations  of  replenishment  requirements.  Initial  allowances 
must  often  be  computed  on  the  basis  of  engineering  estimates  since  little  or  no 
historical  data  are  available.  As  historical  demand  on  the  system  is  accumulated, 
requirement  computations  usually  change.  However,  the  magnitude  of  these 
changes  is  amplified  if,  in  addition  to  the  engineering  estimates  being  supplanted  by 
historical  data,  the  provisioning  and  replenishment  models  employ  different  logic. 
This  problem  could  be  alleviated  if  provisioning  and  replenishment  computations 
used  the  same  model  that  was  designed  to  accept  either  engineering  estimates  or 
historical  demand.  Program  data  are  used  extensively  during  computation  of  initial 
allowances.  Those  data  should  also  be  used  by  the  inventory  models  to  adjust 
requirements  during  the  phase-out  oeriod  of  a  weapons  system. 
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FIGURE  D-8.  SUPPLY:  WHOLESALE  INVENTORY  MANAGEMENT  FUNCTIONS 


WHOLESALE  INVENTORY  MANAGEMENT 


.1  Inventory  requirements 
.1.1  Provisioning 
.1.2  Wholesale  requirements 
.1.3  War  materiel  requirements 
.2  Identify  requirements  parameters 

.3  Determine  quantitative  amount  by  acquisition  source 
(contract,  excess,  disposal,  other  wholesale  unit) 

.4  Prepare  procurement  request 
.5  Requisition  (stock  repositioning) 


.1  item  identification 
.1.1  Item  entry 

.1.2  Item  interchangeability 

.1.3  Item  reduction 

.2  Catalog  management  data  collection  and  distribution 
.3  Documentation  /  publication 
.4  Logistical  reassignments  (catalog  changes) 


2  Replenishment 

3  Due-in,  pre-positioning 


.1  Purpose,  ownership,  condition 
.2  Losses,  gams 

6  Demand  accumulation 

7  Re-identification  (catalog  changes) 

8  Quality  control  (of  receipts) 

9  Logistical  reassignments  (negotiated) 

10  Shelf  life 


1  Determine  logistical  support  requirements 

2  Stockage  pattern 

3  Stratification 

4  Redistribution 
4.1  Wholesale 


Continued  on  next  page 
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RETAIL  EXCESS 
PROCESSING 
(RETURNS) 


WHOLESALE 


.1  Retail  excels  reporting  to  ICPs 
.2  Disposition 

.2.1  Take-up  in  wholesale  stock 
.2.2  Redistribution 
.2.3  Local  reutilization 
.3  Repairable  return  /  exchange 


.1  ICP  determination  of  wholesale  excess 
.2  Oisposal  release  (to  disposing  function) 


Documentation 
.1.1  Customer  reporting 
.1.2  Wholesale  receipt  discrepancies 
Investigation 
.2.1  Inspection 
.2.2  Inventory 
2.3  Other  causative  research 


.3.1  Response 

3.2  Adjustments 
3.2.1  Credit 
.3.2.2  Stock 

3.3  Materiel  disposition 


TABLE  0-6.  DESCRIPTIONS:  SUPPLY/WHOLESALE  INVENTORY  MANAGEMENT  FUNCTIONS 


FUNCTIONS 

DESCRIPTIONS 

3  2 

Wholesale 

Inventory 

Management 

The  management  and  control  of  inventory  under  the  direction  of  the  ICP,  which  maintains  quantities  of 
stock  to  satisfy  requisitions  from  the  retail  level.  These  are  inventories,  regardless  of  funding  source, 
over  which  an  IM  at  the  national  level  has  asset  knowledge  and  exercises  unrestricted  asset  control  to 
meet  worldwide  inventory  management  responsibilities 

3.2.1 

Requirements 
Computation 
and  Acquisition 

Requirements  computation  is  an  on-gomg  process  performed  to  support  and  augment  the  wholesale 
inventory  acquisition  process.  It  is  the  computation,  using  various  mathematical  models,  of  the  quanti¬ 
ties  of  supplies  and  spare  parts  needed  to  meet  the  requisitioning  demands  of  retail-level  users.  The 
first  stage  of  requirements  computation  associated  with  maior  end  items  is  initial  provisioning  and 
allowance  lists.  This  process  identifies  the  spare  parts  for  repair/replacement  to  be  delivered  with  the 
end  item  As  the  end  'tern  is  used  operationally,  a  parts-demand  history  develops  Requirements 
computation  is  then  based  on  the  demand  history  trends  integrated  with  other  requirements 
information,  such  as  program  operational  requirements,  insurances  requirements,  etc  The  actual  spare 
parts  acquisition  process  is  further  factored  by  economic  order  quantities  (or  annual  buy  quantities)  to 
determine  a  best-buy  amount  for  replenishment  As  a  maior  end  item  is  phased-out  of  the  active 
inventory,  the  requirements  computation  process  should  again  be  changed  to  utilize  demand  mstory 
factored  and  weighted  by  operational  levels  and  phase-out  estimates  to  reduce  parts  surplus  as  the  use 
of  the  end  item  is  terminated.  Basic  policy  guidance  for  initial  provisioning  and  for  requirements 
computation  for  secondary  items  is  provided  in  DoDD  4140  40  and  41 40  42  respectively 

For  commodities  not  directly  associated  with  end  items,  the  requirements  computation  is  based  on 
historical  demand  trends  factored  and  weighted  by  economic  order  or  annual  buy  quantities 

3.2.2 

Cataloging 

Cataloging  consists  of  naming,  identifying,  classifying,  and  numbering  items  of  property.  Responsibility 
for  technical  research  and  item  identification  rests  with  the  iCPs  m  each  S/A  it  is  basic  policy  of  the 
Federal  Catalog  System  that  each  item  of  supply  will  be  described  and  classified  in  such  a  manner  that  it 
is  identified  by  a  single  stock  number  The  system  encompasses  all  items  subiect  to  stockage  for  supply 
system  support  or  subiect  to  repetitive  procurement,  distribution,  and  issue 

3  2.3 

Inventory 

Control 

Inventory  control  includes  maintenance  of  stock  levels  and  replenishment  of  these  levels  so  that 
(1 )  items  are  supplied  to  using  organizations  when  and  where  they  are  needed;  (2)  overall  investment 
in  inventories  is  kept  to  a  minimum,  consistent  with  the  need;  and  (3)  the  workload  of  supply  trans¬ 
actions  (including  procurement  actions  and  stock  status  and  transaction  reporting)  is  controlled,  in 
both  detail  and  frequency 

3.2.4 

Distribution 

and 

Redistribution 

These  are  the  logistics  processes  that  cover  positioning  of  materiel  at  specific  storage  points  and 
movement  of  materiel  between  storage  points  (redistribution)  Time,  distance,  and  load  factors  of  the 
defense  distribution  system  play  major  roles  in  the  successful  deployment  of  military  capability  and 
determine,  to  a  large  extent,  the  size  of  the  inventory  and  investment  needed  to  maintain  supplies  in 
the  hands  of  the  U  S.  fighting  force  Distribution  systems  consist  of  a  complex  series  of  echelons  of 
supply,  which  extend  from  the  ICP  through  a  depot  system  and  subsidiary  storage  points  to  the 
ultimate  consumer  on  the  flight  line,  aboard  the  ship,  or  in  the  field  To  be  efficient,  these  systems 
must  (1)  be  responsive  to  the  customer,  (2)  have  the  ability  to  expand  rapidly  in  times  of  national 
emergency,  (3)  be  economical  to  operate,  and  (4)  be  resistant  to  disruption  by  overt  or  covert  actions 

3  2  5 

Repair 

and/or 

Rebuild 

Maintenance  is  a  major  contributor  to  defense  operational  readiness  Many  items  of  equipment  anc 
subassemblies  of  end  items  are  designed  as  repair  or  rebuild  at  different  levels  of  field  or  depc' 
maintenance.  To  support  these  maintenance  functions,  supply  inventories  must  have  spare  parts  avail¬ 
able  to  meet  maintenance  demand  Thus,  data  generated  in  overhaul  and  maintenance  operations  are 
essential  to  accurate  determinations  concerning  the  range  of  items  to  be  carried  in  supply  inventories 
and  the  stock  levels  to  be  maintained 

3  2  6 

Requisition 

Processing 

Requisition  processing  covers  demands  or  requests  for  materiel  against  wholesale  inventory  records  for 
the  purpose  of  issuing  materiel  in  response  to  requisitions,  in  accordance  with  established  issue  pr'ority 
system  guidelines,  and  the  framework  of  related  processes  before  materiel  is  released  for  shipment 

The  UMMIPS  helps  satisfy  the  need  to  identify  the  relative  importance  of  competing  demands  for 
logistics  system  resources  such  as  transportation,  warehousing,  data  processing,  and  materiel 
inventories  The  system  establishes  guidance  for  ranking  materiel  requirements,  as  well  as  incremental 
time  standards  for  processing  requisitions  and  moving  materiel 

3  2  7 

Retail  Excess 
Processing 
(Returns) 

This  term  refers  to  logistics  processes  related  to  review,  authorization,  and  disposition  of  materiel 
reported  from  below  the  wholesale  level  that  is  identified  as  surplus  or  excess  to  projected  needs 

3  2  8 

Wholesale 

Excessmg 

Excesses  are  determined  by  the  National  ICPs,  using  economic  retention  criteria,  as  part  of  me  process 
of  requirements  determination  The  retention  formula  shows  when  the  COST  of  retaining  an  item  s 
equal  to  the  cost  of  disposing  of  it,  with  the  knowledge  that  procurement  may  be  necessary  at  a  later 
date 

3  2  9 

Discrepancies 

This  is  the  process  of  documenting  and  resolving  discrepancies  in  materiel  and  shipments,  including 
supply-type,  quality,  and  transportation  discrepancies 

-55 


Other  procedure®  that  should  be  included  in  the  DLSS  are: 

•  Provisioning  procedures,  to  support  early  logistics  organizational  involve¬ 
ment  and  specification  of  manual  and  automated  interfaces  between 
weapons  system  development  and  weapons  system  operational  mainte¬ 
nance  logistics 

•  Retail  demand  stockage  levels  and  user-requirement  forecasts  based  on 
projected  operations  levels,  both  of  which  must  be  considered  and  factored 
into  determining  wholesale  requirements 

•  Control  and  management  of  war  reserve  materiel  requirements,  which 
should  be  standardized  throughout  DoD  as  part  of  both  implementation  of 
weapons  system  management  procedures  and  improvement  in  interfaces 
between  Services  and  joint  activities  .  This  procedure  is  discussed  in  more 
detail  in  Part  II,  Section  A.5. 

MODELS  Requirement:  The  expanded  DLSS  must  develop 
DoD  standards  for  analysis  of  demand  and  presentation  of 
requirements  data,  including  initial  provisioning  procedures 
and  the  control  and  management  of  war  reserve  materiel 
requirements. 


D.2.b  Cataloging. 

The  DIDS  is  a  DoD-wide  system  administered  by  DLA  and  operated  by  the 
Defense  Logistics  Services  Center  (DLSC)  and  is  the  national  cataloging  data  base 
for  more  than  4  million  items  designated  and  specified  by  an  NSN.  S/As  perform 
their  own  cataloging  under  standard  rules  prescribed  by  DLSC.  However,  weapons 
system  identification  and  a  broad  range  of  related  logistical  functions  are  expected  to 
become  key  issues  for  MODELS.  Because  of  the  expanded  scope  of  the  DLSS 
discussed  here,  as  well  as  other  issues  and  considerations  discussed  throughout  the 
remainder  of  this  report,  consideration  must  be  given  to  coordinating  cataloging 
interface  standards  into  the  MODELS  conceptual  design,  particularly: 

•  Item  Identification 


Cataloging  of  new  supply  items,  including  weapons  system  application 
data,  pilferable  and  sensitive  item  identifiers,  and  hazardous  materiel 
codes 


Interchangeability  and  substitutability  between  items 

Item  reduction  —  redundancy  versus  unique-application  specificity 


•  Catalog  management  —  maintenance  of  S/A  data  bases,  need  for  DAAS- 
type  catalog  data  and  source  of  supply  validations 

•  Documentation  and  publication  —  on-line  access,  use  of  new  media,  such  as 
optical  disk  technology 

•  Logistical  reassignments  (because  of  catalog  changes). 

MODELS  Requirement:  The  MODELS  concept  should  review 
DIDS  modernization  requirements  and  plans  and  closely 
coordinate  the  MODELS  conceptual  design  to  accommodate 
future  DIDS  capabilities. 

D.2.c  Inventory  Control. 

MILSTRAP  is  now  the  DLSS  vehicle  for  prescribing  inventory  control  interface 
standards.  However,  some  procedures  are  directed  by  other  publications,  such  as 
DoD  4140. 26-M,  "Defense  Integrated  Materiel  Management  Manual  for  Consumable 
Items.”  A  comprehensive  set  of  DLSS-expanded  inventory  control  interface  stan¬ 
dards  should  include  procedures  for: 

•  Issue  processing 

•  Replenishment  actions 

•  Establishment  of  due-ins,  pre-positioning  —  a  standardized  data  base 
design  would  facilitate  the  use  of  bar-code  technology  in  receipt  processing 

•  Receipts  —  processing  and  inventory  accounting,  interface  with  depot  func¬ 
tions 

-  Receipts  from  vendors  —  interface  with  contract  administration  and 
quality  assurance  functions 

-  Returns  from  customers  —  interface  with  redistribution  and  reutiliza¬ 
tion  functions 

•  Adjustments  to  inventory 

-  Purpose,  ownership,  condition  coding,  and  changes 

-  Losses,  gains  of  inventory  —  accountability,  interface  with  physical 
inventory  function 
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•  Demand  accumulation  —  interface  with  retail  requirements 

•  Re-identification  (catalog  changes) 

•  Logistical  reassignments  (negotiated). 

The  Integrated  Material  Manager  (IMM)  should  have  DoD-wide  asset  visibility 
down  to  the  lowest  supply  echelon  and  should  maintain  visibility  of  items  in  R&M. 
The  IMM  could  use  this  visibility  of  wholesale  and  retail  stocks  after  consultation 
with  retail  stock  managers  concerning  near-term  local  requirements,  to  make  deci¬ 
sions  pertaining  to  procurement,  repair,  retention,  and  disposal.  The  IMM  would 
thus  be  in  a  better  position  to  recommend  redistribution  of  excess  stocks,  when 
appropriate,  and  to  help  facilitate  emergency  access  to  DoD  inventories  that  may  not 
be  in  excess.  The  Services  now  lack  the  full  asset  visibility  required.  Moreover, 
visibility  of  assets  in  the  "industrial  funds”  is  minimal.  A  higher  level  of  asset  visi¬ 
bility  should  be  incorporated  into  the  MODELS  concept,  if  possible. 

MODELS  Requirement:  All  inventory  management  and  con- 
trol  issues  and  procedures  should  be  integrated  in  an  expanded 
DLSS.  Within  this  integrated  environment,  the  MODELS 
design  must  provide  the  IMM  the  capability  for  on-line  DoD- 
wide  asset  visibility. 

D.2.d  Distribution  and  Redistribution. 

Distribution  and  redistribution  are  partially  standardized  under  MILSTRIP 
and  MILSTRAP.  However,  authority  and  procedures  for  secondary  item  asset 
visibility  and  lateral  redistribution  is  provided  under  DoDI  4140.37,  Asset  Knowl¬ 
edge  and  Control  of  Secondary  Items.  In-theater,  lateral  redistribution  is  still 
largely  limited  to  Defense  European  and  Pacific  Redistribution  Activity  (DEPRA) 
processing  at  the  Defense  Automated  Addressing  System  Office  (DAASO),  pre 
scribed  in  DoD  4140. 17-M,  Supplement  3,  MILSTRIP  DEPRA  Procedures.  During 
the  past  several  years,  an  attempt  has  been  made  to  consolidate  material  returns 
and  redistribution  under  one  procedure.  The  Approved  MILSTRIP  Change  Letter 
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(AMCL)  121  A,  Materiel  Returns  Program  (MRP)  Redistribution  Procedures,  would 
have  placed  all  distribution,  returns,  and  redistribution  procedures  under  the 
responsibility  of  the  IMM;  however,  the  attempt  failed  and  the  proposal  was 
withdrawn.  In  July  1986,  the  Army  opened  the  European  Redistribution  Facility  to 
ensure  economical  reutilization  of  assets  within  theater  before  returning  excess 
asset  to  CONUS  depots. 

To  optimize  the  efficiency  of  the  distribution  of  demand  and  replenishment 
stocks  and  the  redistribution  of  surplus/excess  material,  however,  the  IMM  needs 
full  visibility  of  available  assets,  as  discussed  in  Section  D.l.e  and  further  described 
in  Section  F.l. 

MODELS  Requirement:  Distribution  and  redistribution  proce¬ 
dures  should  be  consolidated  under  one  expanded  DLSS  proce¬ 
dure  for  wholesale  supply  management. 

D.2.e  Repair  and/or  Rebuild. 

Repair  and/or  rebuild-related  information  exchange  transactions  within  DLSS 
procedures  are  very  limited.  MILSTREP  provides  a  transaction  for  automatic  return 
and  reissue  of  reparable  carcasses  (Nonconsumable  Item  Material  Support  Code, 
NIMSC5,  unserviceable  items),  with  notifications  between  Primary  Inventory 
Control  Activities  (PICAs)  and  Secondary  Inventory  Control  Activities  (SICAs)  of 
the  return  and  the  storage  activity  to  which  the  item(s)  are  being  shipped.  Several 
other  repair  and/or  rebuild  activities  affect  supply  wholesale  inventories,  but 
standard  inter-S/A  transactions  do  not  now  exist  for  exchanging  pertinent  infor¬ 
mation.  The  modernized,  expanded  DLSS  must,  therefore  include  a  full  interface  to 
maintenance  requirements,  particularly  depot-level  maintenance  and  commercially- 
operated  maintenance.  Standard  policies  and  procedures  should  be  developed  for 
exchange  and  reissue,  and  specific  rules  and  formulas  should  be  defined  for  the  level 
of  credit  allowed. 


MODELS  Requirement:  The  MODELS  concept  must  provide 
an  automated  information  interface  for  maintenance  require¬ 
ments.  The  modernized  DLSS  must  provide  for  the  induction 
and  return  of  reparables,  so  that  the  IMM/IM  (owning)  has  the 
necessary  asset  visibility  to  allow  for  proper  control,  and  to 
take  asset  status  into  consideration  when  performing  procure¬ 
ments  and  redistributions. 


D.2.f  Requisition  Processing. 

Requisition  processing  is  extensively  covered  in  MILSTRIP  procedures. 
MODELS,  however,  will  incorporate  the  additional  functional  elements  (require¬ 
ments,  source-of-supply  determination,  etc),  shown  in  Figure  D-8  and  discussed  in 
the  following  subsections.  Within  the  modernized  function,  several  additional  stan¬ 
dardized  procedures  should  be  included. 

A  requirement  that  must  be  addressed  during  development  of  the  variable- 
length-record  transaction  is  the  provision  of  accurate  system  tracking  of  split  or 


partial  supply  actions  and  suffix  assignments.  One  solution  might  be  to  include  both 
suffix  split  from  and  the  current  suffix  in  the  variable-length  transaction;  that  would 
provide  improved  supply  management. 

MODELS  Requirement:  Requisition  history  retention  periods 
for  each  type  of  transaction  should  be  standardized.  Visibility 
of  referrals,  backorders,  depot  denials,  and  cancellations 
should  be  enhanced. 

Another  standardized  procedure  should  address  the  response  of  the  logistic 
system  to  JCS  and  Unified  Command  direction  in  crisis  or  war  regarding  allocation 
of  materiel.  The  logistic  system  must  be  able  to  allocate  materiel  correctly  in 
response  to  JCS  objectives  and  Unified  Command  requirements. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  correct  response  of  the  logistic  system  to  JCS  and  Unified 
Command  allocation  guidance. 


D.2.f(l)  Requisition  Edits. 

Requisition  edits,  including  data  validation  (what,  where,  by  whom)  and 
priority  (UMMTPS  and  additional  rules  imposed  by  policy),  evolved  gradually  in  the 
present  DLSS.  Conflicting  priorities  (e.g.,  supply  versus  transportation)  must  be 
resolved,  first  by  policy,  then  by  implementation  in  the  DLSS.  Many  MILSTRIP  and 
S/A  unique  edits  are  being  performed  by  D  AAS. 

MODELS  Requirement:  The  use  of  priority  codes,  project 
codes,  and  weapons  system  codes  in  the  requisition  transaction 
must  be  defined  and  accommodated  in  the  MODELS  concept. 
Requisition  edits  by  the  supply  source  and  intervening  third 
parties  (such  as  DAAS)  need  to  be  integrated  under  the  DLSS. 

D.2.f(2)  Source-of-Supply  Determination. 

Source-of-supply  information  is  maintained  today  by  requisitioners,  DAAS, 
DLSC,  and  the  supply  source.  Redundancy  is  widespread  and  thus  conflicts  are 
frequent.  Separate  catalog  data  bases  contribute  to  the  problem.  Automated  routing 
of  transactions  can  lead  to  "pingponging”  between  processing  points.  Errors  cross 
functional  boundaries  and  are  therefore  difficult  to  resolve. 

MODELS  Requirement:  MODELS  should  provide  a  better 
approach  to  accessing  source-of-supply  information  and  to 
resolving  conflicts. 

D.2.f(3)  Methods  of  Supply  Determination. 

Methods  of  supply  determination  processes  include  determining  supply  source, 
creating  and  maintaining  of  updated  catalog  information,  and  timely  notification  to 
the  requisitioner  of  supply  source  actions  and  the  effects  on  delivery  schedules, 
pricing,  and  availability.  These  three  processes  are  not  addressed  by  the  DLSS. 


MODELS  Requirement:  MODELS  must  establish  standards 


D.2.fU)  Materiel  Release  Processing. 

MILSTRTP  prescribes  standard  transactions  for  materiel  release,  materiel 
release  confirmation,  materiel  release  denial,  and  Navy-unique  referral  orders. 
Serious  problems  exist  in  processing  and  controlling  of  these  functions,  and  those 
problems  tend  to  cross  S/'A  lines  and  are  both  causes  and  effects  of  discontinuities 
between  depot  and  ICP  inventory  and  issue  systems,  as  well  as  loss  of  inventory 
accountability.  Automated  information  collection  procedures  as  a  normal  function  of 
operations  are  needed  to  provide  a  means  of  tracking  MROs  at  depots  and  of  ensur¬ 
ing  accurate  reporting  of  Materiel  Release  Confirmations  (MRCs).  Improved  inter¬ 
faces,  including  on-line  access,  may  be  required  for  balancing  ICP  and  depot  records; 
as  discussed  later  in  Part  II,  Section  B.5,  a  unified  data  base  may  be  both  required 
and  feasible  under  MODELS.  Billing  is  not  consistently  integrated  with  release 
procedures,  resulting  in  discontinuities  between  the  processes. 

MODELS  Requirement:  The  MODELS  concept  should  include 
a  method  for  providing  denial  status  directly  to  requisitioners 
either  at  a  retail-supply  point  or  through  the  retail-supply 
point  system  to  end-user  requisitioners.  Standardized  proce¬ 
dures  and  time  frames  are  needed  to  improve  data  retention  for 
depot  records  and  for  the  use  of  constructive  delivery-and- 
receipt  concepts  for  billing  purposes  throughout  all  levels  of 
the  logistics  community. 

D.2.fI5)  Status. 

Requirements  for  batch  processing  and  automatic  transmission  of  requisition 
status  (pushed)  should  be  evaluated  in  light  of  new  system  architecture  alternatives. 
The  issue  is  whether  to  continue  pushing  transactions  based  on  the  requisitioner- 
coded  instructions  or  to  limit  pushed  transactions  being  communicated  to  requisi¬ 
tioning  facilities  to  specific  situations.  As  a  result  of  the  present  push  procedure, 
large  volumes  of  transactions  (more  than  6  million  a  month)  are  communicated  to 
requisitioning  facilities  as  well  as  centralized  repositories  of  logistics  data. 
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MODELS  Requirement:  MODELS  should  evaluate  the 
continuing  need  for  pushed  follow-ups,  especially  to  update 
centralized  data  bases  maintained  by  the  S/As,  if  interactive 
inquiry  gateway  capability  is  established  throughout  the  logis¬ 
tics  system  network.  This  change  would  require  that  stan¬ 
dardized  procedures  and  guidelines  be  promulgated  for  inquiry 
capability. 

D.2.fX6)  Modifiers. 

Modification  of  requisition  data  in  the  current  DLSS  procedures  is  cumber¬ 
some.  In  addition,  once  a  requisition  has  entered  the  issue  cycle,  it  is  virtually 
impossible  to  modify  any  aspect  of  its  properties,  from  the  quantity  to  the  ship-to 
address.  Still,  the  logistics  system  is  constantly  in  motion  —  demands  change  and 
units  move.  Therefore,  MODELS  must  develop  procedures  for  expanding  and 
enhancing  requisition  modification  techniques.  These  improved  procedures  must 
accommodate  and  facilitate  mass  modifications  associated  with  unit  movements,  i.e., 
mass  changes  of  ship-to  addresses. 

The  most  obvious  solution  is  the  incorporation  of  on-line,  interactive  change 
capability.  However,  accountability  safeguards  and  audit  trails  must  be  established 
to  make  sure  that  a  transaction  history  is  maintained,  that  access  is  duly  authorized, 
and  that  such  changes  as  ship-to  address  are  authenticated  to  prevent  fraud  and 
abuse. 

D.2.fX7)  Cancellations. 

Cancellations  now  face  the  same  difficulties  as  modifications,  in  that  once  the 
issue  cycle  starts,  canceling  a  requisition  is  very  difficult.  However,  improved  infer 
mation  requirements,  forecasting,  and  visibility  of  assets  and  status  will  increase 
the  user’s  information  base  for  cancellation  decisions.  On  the  other  hand,  greater 
visibility  and  more  timely  availability  of  information  should  also  reduce  the  need  for 
cancellations,  particularly  mass  cancellations. 


Improved  cancellation  procedures  are  particularly  important  for  overseas  ship¬ 
ments.  These  procedures  must  interface  with  transportation  management  and  port 
operation  systems  to  enhance  capability  for  intercepting  and  diverting  shipments. 

MODELS  Requirement:  MODELS  must  incorporate  improved 
interface  capabilities  to  permit  timely  processing  of  modifica¬ 
tions  and  cancellations.  Also,  modernized  DLSS  must  include 
procedures  and  standard  rules  concerning  the  stages  at  which 
changes  can  be  made  (during  which  segments  of  the  pipeline 
process),  what  changes  are  authorized  with  various  modes  of 
data  access  (interactive  versus  transactional),  and  who  is 
authorized  to  initiate  interactive  changes,  taking  appropriate 
precautions  on  access  and  record- level  security. 

D.2.f(8)  Backorders. 

Backorder  processing  procedures  should  be  improved  under  MODELS.  The 
present  follow-up  response  to  backordered  material  is  a  manual,  sometimes 
overlooked,  process.  Not-mission-capable-supply  requirements  may  be  backordered 
routinely.  The  process  should  be  integrated  with  present  contract  administration 
procedures  to  provide  automatic  updates  to  the  IM  and  the  requisitioner  on  the 
contract  award  schedule,  expected  delivery  schedule,  and  any  changes  in  projected 
delivery  dates.  When  a  requisition  enters  the  backorder  process,  such  performance 
standards  as  UMMIPS  are  no  longer  applicable.  While  backorder  processing  is 
measured  indirectly  in  MILSTEP  Format  2  (ICP  availability  performance)  and 
Format  IB  (pipeline  performance  for  delayed  issue),  additional  direct  measure¬ 
ments,  for  example,  average  time  and  quantity  in  backorder  by  priority  code,  are 
needed  if  the  backorder  process  is  to  get  appropriate  operational  and  management 
attention. 

An  issue  of  particular  importance  is  development  and  implementation  of 
ndard  procedures  for  special  processing  Priority  Group  1  requisitions  in  a  back 
order  status.  Exception  purchase  or  local  purchase  rules  should  be  developed  and 
implemented  for  the  IM. 
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The  Materiel  Obligation  Validation  (MOV)  process  should  be  reviewed  again. 
New  technology,  modified  DLSS  procedures,  and  more  frequent  "electronically 
mailed”  internal  validations  may  remove  the  need  for  the  cyclic  MOV  procedure. 
While  the  MOV  process  is  in  place,  however,  the  effects  of  MOV  procedures  should  be 
tracked  better  so  that  its  real  effects  can  be  compared  with  perceived  cost  savings. 

Automating  the  contract  administration  process  and  providing  access  to  more 
timely  contract  performance  information  should  result  in  more  realistic  release 
dates  on  vendor  deliveries. 


MODELS  Requirement:  DLSS  guidelines  and  procedures  for 
processing  backorder  releases  need  to  be  developed  and  imple¬ 
mented.  A  priority  processing  scheme  similar  to  that  used  for 
in-process  requisitions  should  be  applied  to  backorder  release 
processing.  Partial  shipments  of  priority  materiel  should  be 
considered,  and  rules  and  automated  procedures  should  be 
developed  to  standardize  when  such  shipments  can  be  autho¬ 
rized  and  by  whom. 


D.2.g  Retail  Excess  Processing  (Returns). 

Standard  procedures  should  be  implemented  in  the  requisitioning  process  to 
require  interface  with  and  search  of  normal  and  declared  excess  stock  available  at 
retail  levels  before  processing  additional  procurements.  Improved  visibility  of  retail 
assets,  as  noted  earlier  in  Section  D.l.e,  is  vital  to  successful  improvement  of  excess 
processing.  If  materiel  is  backordered,  automated  procedures  should  be  imple¬ 
mented  to  perform  a  thorough  daily  or  weekly  search  of  the  logistics  network(s), 
electronically,  for  newly  identified  excess  retail  stocks. 

To  complement  improved  excess  identification  procedures,  the  DLSS  should 
develop  DoD-wide  redistribution  procedures  to  be  automated  in  the  MODELS  itnple 
mentation. 


MODELS  Requirement:  MODELS  must  improve  IM  visibility 
of  retail  excess  materiel.  Also,  the  DLSS  should  identify  proce¬ 
dures  to  integrate  retail  returns  with  discrepancy  processing 
systems. 
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D.2.h  Wholesale  Excessing. 

Wholesale  excess  materiel,  although  still  in  good  condition,  must  be  entered 
quickly  into  an  automated,  on-line  reutilization  and  marketing  data  base  so  that  its 
availability  will  be  widely  known.  The  disposal  turn-in  procedures  should  be 
changed.  Materiel  proposed  for  excessing  should  be  identified  earlier,  availability 
dates  should  be  announced  as  soon  as  possible,  and  the  condition  coding  process 
should  be  improved. 

MODELS  Requirement:  Procedures  for  ICP  determination 
and  processing  of  wholesale  excess  materiel  need  improve¬ 
ment. 

D.2.i  Discrepancies. 

Although  only  RODs  are  in  the  current  DLSS  scope  of  standardization,  the 
various  DLSS  also  have  incomplete  interfaces  with  TDRs  and  QDRs.  These 
interfaces  should  be  complete  to  maximize  the  effectiveness  of  the  discrepancy 
reporting  process. 

Functions  to  be  included  in  standardized  discrepancy  procedures  are: 

•  Documentation  —  electronic  data  interchange  interfaces  with  industry 
(vendors  and  carriers) 

-  Customer  reporting  —  automation  under  MRASDRS 

-  Wholesale  receipt  discrepancies  —  coverage  in  MILSTRAP  and 
MRASDRS 


•  Investigation  and  research  into  shipment  records,  shipment  tracing,  and 
other  causative  factors,  including 

-  Inspection  —  interface  with  quality  assurance  function 

-  Inventory  —  interface  with  physical  inventory  function 

•  Disposition 

-  Response  to  customers,  contract  administration  actions,  carrier  claims, 
etc. 


-  Adjustments 

•  Credits 

•  Stock  replacement 

•  Materiel  disposition. 

Incorporation  and  interface  of  all  discrepancy  reports  and  procedures  would 
improve  cross-correlation  of  problems.  For  example,  the  procedures  could  link  RODs 
and  inventory  discrepancies  to  determine  whether  a  shipment  receipt  shortage  is 
correlated  with  an  inventory  overage,  or  vice  versa.  Similarly,  QDRs  might  be 
related  to  TDRs  that  are  reported  with  excess  delivery  times.  This  integration 
would  improve  the  whole  reporting  process  and  may  assist  in  identifying  causal 
relationships  or  deficiency  trends. 

MODELS  Requirement:  The  DLSS  should  define  a  standard 
set  of  reporting  procedures  for  all  types  of  discrepancies,  in  one 
procedural  document.  The  MODELS  concept  should  consider 
methods  for  automated  integration  of  deficiency  reporting 
procedures,  through  data  base  techniques  and  on-line,  inter 
active  information  retrieval  capabilities. 

D.3  Technical  Data  Management. 

Technical  data,  which  is  the  link  between  personnel  and  equipment,  includes 
operating  and  maintenance  procedures,  special  test  procedures,  installation  instruc¬ 
tions,  checklists,  change  notices  and  change  procedures,  drawings,  photographs,  etc., 
for  the  weapons  systems,  support  equipment,  training  equipment,  transportation 
and  handling  equipment,  and  repair/replacement  assemblies  and  parts.  Technical 
data  management  is  the  function  that  embraces  identifying,  coordinating,  collating, 
validating,  integrating,  and  controlling  technical  data  requirements;  ensuring  the 
adequacy  of  cataloged  technical  data;  and  managing  the  use  of  technical  data  assets 
after  receipt.  [Note:  The  acquisition  of  technical  data  during  contract  performance 
or  through  procedures  such  as  reverse  engineering,  is  covered  under  Technical  Data 
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Acquisition  in  Section  C.3].  The  function  also  includes  standardizing  the 
distribution  of  data  acquired  under  contract  and  developing  standard  procedures  for 
storage,  retrieval,  and  disposal  of  technical  data. 

D.3.a  Use  and  Management  of  Technical  Data. 

On-line  access  to  technical  data,  drawings,  and  pictures  will  reduce  or  elim¬ 
inate  off-line  documentation  of  exception  requirements  data  and  make  possible 
greater  control  of  the  proliferation  of  locally-assigned  stock  numbers  by  encouraging 
positive  identification  of  part  numbers  to  NSNs  before  requisitions  are  generated. 
Requisitions  for  items  that  are  not  identifiable  immediately  can  be  suspended  for 
interactive  inquiry  and  data  exchange. 

Procedures  will  be  needed  to  define  standards  for  the  use  and  transmission  of 
technical  data.  Developing  those  procedures  could  be  a  major  undertaking,  consider¬ 
ing  the  classified  and/or  proprietary  nature  of  large  amounts  of  technical  data.  The 
MODELS  concept  should  explore  methods  to  handle  the  storage  and  transmission  or 
other  distribution  of  technical  data  that  is  classified,  proprietary,  or  both.  These 
functions  are  being  extensively  reviewed  and  evaluated  by  the  OSD  CALS  project. 

MODELS  Requirement:  DLSS  procedures  need  to  be  devel- 
oped  to  define  standards  for  the  use  and  transmission  of 
technical  data.  The  MODELS  design  must  allow  and  promote 
on-line  access  to  catalog  and  technical  data,  with  full  graphics 
capability  for  transmission  and  display  of  digitized  images. 

This  capability  must  incorporate  CALS-developed  procedure 
and  protocol  standards  as  discussed  in  Parti,  Section  C.3. 

DoDIs  establish  the  DoD  technical  data  management  program  and  define 
uniform  policies  and  procedures  for  management  and  administration  of  (1)  technical 
data  acquired  contractually  in  support  of  contract  end-items,  (2)  technical  data 
developed  within  DoD,  and  (3)  the  DoD  Management  Improvement  Program  con 
cerned  with  the  life  of  technical  data. 


These  procedures  and  policies  are  mandatory  in  the  management  of  internally 
prepared  as  well  as  contractually  prepared  data  and  also  apply  to  furnishing  of 
technical  data  to  GSA  for  items  managed  by  GSA  for  DoD.  These  procedures  are  not 
now  within  the  scope  of  DLSS  functional  responsibilities. 

A  number  of  repositories  of  technical  data  exist  throughout  DoD.  Some  are 
manual  operations  with  plans  to  automate;  others  have  an  index  to  the  data 
maintained  in  their  data  bases,  accessible  through  separate  log  on  procedures  and 
not  accessible  by  remote  users.  These  data,  filed  by  drawing  number  and  related  to 
part  number(s),  include  drawings,  specifications,  test  requirements,  and  other  data 
used  to  support  cataloging,  procurement,  reverse  engineering,  and  other  logistics 
activities.  DoD,  other  Federal  Agencies,  and  some  international  organizations  use 
these  data. 

DLA  is  now  tasked  to  develop  a  data  base  index  of  technical  drawings.  What  is 
needed,  however,  is  more  than  an  index  to  technical  data.  Once  the  drawing  is 
located,  the  user  should  be  able  to  retrieve  the  information  on-line.  Seeking,  obtain¬ 
ing,  and  transmitting  engineering  technical  information  should  be  an  '  itegral  part 
of  the  logistics  system. 

While  the  Services  are  updating  automated  procedures  for  retrieval  of  tech¬ 
nical  data,  their  efforts  do  not  appear  to  be  coordinated  .  Thus,  those  efforts  will 
likely  result  in  heterogeneous  hardware  and  software  that  must  be  interfaced  when 
information  is  retrieved  by  one  S/A  from  another.  Thus,  the  MODELS  concept  must 
incorporate  the  capability  to  transmit  technical  data  specifications  and  drawings 
between  heterogeneous  systems. 

OSD  is  sponsoring  implementation  of  the  CALS  system  environment.  That 
project  addresses  many  aspects  of  technical  data  acquisition  and  management, 
including  classified  and  proprietary  data,  contract  clauses,  data  maintenance, 
transmission  protocols,  and  related  requirements  for  effective  technical  data  usage 


throughout  DoD.  However,  engineering  drawings  and  technical  data  will  not  be 
accessible  through  the  individual  Service  systems  for  2  to  3  years,  and  the  CALS 
project  will  be  unable  to  address  protocol  standardization  for  inter-S/A  retrieval  and 
telecommunication  of  technical  data  even  beyond  that  time.  This  standardization, 
when  developed  and  documented,  must  be  integrated  into  the  MODELS  concept  and 
implementation  plan. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
for  standardization  of  procedures  for  the  exchange  of  technical 
data  between  the  S/As. 

Technical  Data  Management  is  divided  into  four  functional  areas:  Acquisition, 
Cataloging,  Storage,  and  Retrieval  and  Exchange.  The  WBS  functions  are  illus¬ 
trated  in  Figure  D-9  and  described  in  Table  D-7. 

D.3.b  Cataloging. 

Technical  data  is  now  referenced  by  a  drawing  number  and  part  number;  it  can 
also  be  traced  through  the  manufacturer’s  identification  code.  Technical  data  must 
be  related  to  the  appropriate  level  of  detail  to  meet  user  requirements,  from  end 
items,  fully  assembled  (e.g.,  tank)  through  subassemblies  and  reparables  (e.g., 
carburetor)  to  individual  parts  (e.g.,  carburetor  float).  Technical  data  cataloging 
procedures  should  accommodate  proprietary  as  well  as  nonproprietary  data  and 
should  provide  the  means  for  easy  and  quick  access  to  technical  data  to  improve  the 
stock  replenishment  process. 

MODELS  Requirement:  The  DLSS  must  provide  for  standard  - 
ization  of  cataloging  activities  related  to  technical  data, 
engineering  drawings,  and  documents,  in  accordance  with  the 
OSD-CALS  Group  recommendations. 

D.3.c  Storage  and  Retrieval. 


Both  manual  and  automated  techniques  are  used  today  for  the  storage  and 
retrieval  of  technical  data  and  engineering  drawings.  The  current  automated 


FIGURE  D-9.  SUPPLY:  TECHNICAL  DATA  MANAGEMENT  FUNCTIONS 
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systems  are  "islands  of  automation”  that  do  not  support  remote  terminal  access  to 
their  data  bases.  The  Services  have  completed  concept  requirements  determination 
and  are  in  the  process  of  selecting  hardware  and  software  to  support  on-line  storage 
and  retrieval  of  technical  data  specifications  and  drawings.  The  OSD-CALS  project 
is  addressing  the  standardization  of  protocols  for  technical  data  storage  and  retrieval 
and  the  development  of  separate  protocols  for  engineering  drawings.  The  standards 
defined  by  CALS  and  the  National  Bureau  of  Standards  (NBS)  will  represent  both 
DoD  and  private  industry. 


TABLE  D-7.  DESCRIPTIONS:  SUPPLY/TECHNICAL  DATA  MANAGEMENT  FUNCTIONS 


FUNCTIONS 

DEFINITIONS 

3  3 

Technical  Data 
Management 

The  management  of  the  recorded  information  needed  to  translate  system  and  equipment 
requirements  into  discrete  engineering  and  logistic  considerations  These  data  are  necessary 
to  develop,  produce,  suppo't,  operate,  and  maintain  systems  and  equipment  in  a  prescribed 
state  of  readiness  Technical  data  is  the  link  between  personnel  and  equipment  and  includes 
operating  and  maintenance  procedures,  special  test  procedures,  installation  instructions, 
checklists,  change  notices  and  change  procedures,  drawings,  photographs,  etc  ,  for  the 
weapons  systems,  support  equipment,  training  equipment,  transportation  and  handlmq 
equipment,  and  repair/replacement  assemblies  and  parts 

3  3  1 

Cataloging 

The  process  of  associating  technical  data  specifications,  drawings,  pictures,  and  related  data 
with  DoD  cataloged  part  numbers  and  NSNs  Technical  data  must  be  related  to  the 
appropriate  level  of  detail  to  meet  user  requirements,  from  end  items,  fully  assembled  (e  g  , 
tank)  through  subassemblies  and  reparables  (e  g  ,  carburetor)  to  individual  parts  (e  g  , 
carburetor  float) 

3  3  2 

Storage 

The  maintenance  of  technical  data  in  repositories  that  protect  the  information  from 
deterioration  and  restrict  access  to  authorized  users  but  allow  easy,  efficient  update  and 
additions  as  physical  configurations  of  materiel  and  equipment  are  changed 

3  3  3 

Retrieval  and 
Exchange 

The  process  of  finding  and  collecting/collating  technical  information  from  the  storage 
repositories  for  dissemination  and  distribution  to  authorized  users 

MODELS  Requirement:  The  DLSS  should  incorporate  the 
findings  and  recommendations  of  the  CALS  project  for  tech¬ 
nical  data  storage  and  retrieval  standardized  procedures. 

D.4  Wholesale  Storage. 

The  wholesale  storage  functions  shown  in  Figure  D-10  should  be  integrated. 
Thus,  DLSS  coverage  should  be  expanded  under  the  MODELS  concept.  Some 
general  procedures  for  wholesale  storage  system  interfaces  to  be  standardized 
include: 

•  A  method  for  correcting  transaction  errors,  with  appropriate  audit  trails,  in 
accountable  transactions.  This  procedure  is  particularly  important  for 
inventory  control  transactions. 

•  A  process  for  improving  reconciliations  of  inventory  between  ICP  account 
able  records  and  storage  site  custodial  records.  This  improvement  can  best 
be  realized  through  distributed  processing  where  there  is  only  one  set  of 
records. 
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FIGURE  D-10.  SUPPLY:  WHOLESALE  STORAGE  FUNCTIONS 
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The  subfunctions  to  be  included  in  the  DLSS  scope  of  coverage  of  wholesale 
storage  are  described  in  Table  D-8.  Subfunctions  with  specific  modernized  DLSS- 
expanded  requirements  are  discussed  below. 

D.4.a  Receipt. 

Receiving  and  receipt  processing  are  now  given  partial  coverage  in 
MILSTRAP,  and  further  automation  is  proposed  under  MRASDRS.  A  critical  need 
within  this  function  is  to  make  performance  tracking  and  reporting  an  integral  part 
of  receipt  processing  rather  than  merely  an  extra  process  of  data  collection  and 
entry.  When  that  is  done,  the  information  will  be  more  accurate  and,  in  addition,  the 
personnel  involved  will  be  more  productive.  Bar  coding  integrated  with  automated 
receiving  systems  and  access  to  financial  in-transits  (accounts  payable  commit¬ 
ments)  to  detect  discrepancies  in  quantity,  will  improve  the  receiving  process 
substantially.  Subfunctions  to  be  included  in  the  receipt  function  include: 

•  Due-in  establishment 

•  Pre-positioning  for  receipts 

•  Receipt  processing 

•  Discrepancy  reporting  for  wholesale  receipts 

-  Report  of  Supply-Type  Discrepancy,  now  included  in  ROD  and 
MILSTRAP 

-  TDR,  now  included  in  a  separate  joint  regulation 

-  QDR,  now  included  in  a  separate  joint  regulation. 

MODELS  Requirement:  Wholesale  receipt  procedures  for 
information  access  and  exchange  between  the  depot  and  ICP 
should  be  fully  covered  under  the  modernized  DLSS,  including 
use  of  bar-coding  technology,  interface  requirements  to  other 
logistics  functions,  and  performance  measurement/quality 
control  processes. 
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TABLE  D-8.  DESCRIPTIONS:  SUPPLY/WHOLESALE  STORAGE  FUNCTIONS 


FUNCTIONS 


Wholesale 

Storage 


Warehousing 
(Depot  Operations) 


Shipment 

Preparation 


Those  logistics  functions  concerned  with  management  and  operation  of  wholesale  materiel  storage 
sites -the  process  of  storing  or  placing  property  in  a  wholesale  warehouse  or  ether  designated 
wholesale  facility,  as  well  as  actions  incident  to  receipt  and  issue  of  such  property 


The  processes  of  inspection,  acceptance,  and  related  actions  incident  to  receipt  of  materiel,  from 
the  time  the  carrier  arrives  at  the  warehouse  dock  until  stocks  are  properly  stored  on  location  and 
reported  to  the  ICP  for  inventory  pickup.  It  is  important  that  this  process  be  completed  quickly  so 
that  shipments  can  be  made  on  time,  backorders  can  be  released  as  soon  as  possible,  ana  Ms  can 
have  timely  balance  information  on  which  to  base  studies  of  requirements 


The  warehousing  operations  encompassing  the  actual  movement  of  materiel  and  space  allocation 
within  a  storage  site  and  the  upkeep  and  maintenance  of  such  materiel  in  place  Supply  managers 
determine  the  proper  storage  location  by  considering  many  factors  -  for  example,  the  length  of 
time  items  may  be  expected  to  stay  in  storage,  the  sources  of  anticipated  demand,  the  amount  of 
space  available,  the  expected  frequency  of  issue,  and  the  anticipated  size  of  issue  An  adequate 
system  for  locating  stocks  must  be  established  and  maintained  so  that  items  can  be  ‘ound  and 
issued  quickly 


The  process  of  accounting  for  and  controlling  stock  on-hand.  It  includes  the  functions  of  physical 
counting,  reconciliation  of  discrepancies,  causative  research,  location  surveys,  and  location  recon¬ 
ciliations 

Physical  counting  is  the  actual  counting  of  the  quantity  of  stock  on-hand  in  a  designated  stowage 
location  and  comparing  the  actual  count  to  the  depot  and  ICP  accounting  system  quantity  records 
Physical  counts  are  performed  usually  for  one  of  two  reasons  First,  a  legal  requirement  for  an 
annual  physical  count  for  items  such  as  ammunition,  controlled  items,  and  classified  items  Second, 
a  discrepancy  between  the  quantity  records  of  the  depot  and  the  official  accountability  records  of 
the  ICP  This  discrepancy  is  most  often  the  result  of  a  depot  denial  to  an  MRO 

Reconciliation  is  the  set  of  procedures,  including  physical  count,  used  to  correct  quantity  differences 
in  inventory  accounting  records  between  the  ICP  and  the  depot 

Causative  research  Is  the  process  of  identifying  reasons  for  the  differences  in  quantity  accounting 
records  between  the  ICP  and  depot.  The  primary  objective  is  identification  and  correction  of 
systemic  problems  with  a  secondary  objective  of  finding  the  cause  of  a  particular  item  discrepancy 

Location  surveys  are  used  to  maintain  the  accuracy  of  the  depot  location  records  The  process 
involves  a  record-to-bm  location  and  bin-back-to-record  reconciliation  Bar-code  readers  are  being 
used  extensively  at  the  depots  to  improve  the  accuracy  and  efficiency  of  location  surveys 

Location  reconciliation  is  a  bottom-up  process,  from  the  depot  to  the  ICP,  identifying  that  a  specific 
NSN  item  is  in  stock  The  procedures  only  identify  that  the  particular  NSN  is  available  at  the  depot 
(depot  location),  not  the  specific  bin  location,  nor  the  quantity  available 


The  process  of  authorizing  and  effecting  release  of  materiel  from  wholesale  inventory  in  response 
to  a  requisition  or  other  validated  requirement  All  supply  systems  have  procedures  for  formally 
releasing  supplies  to  using  activities  or  to  another  echelon  in  the  distribution  system 

If  the  request  for  items  is  within  the  authorized  allowance,  funds  are  properly  cited,  and  no  other 
restrictions  apply,  the  requested  quantities  are  issued  from  available  inventories 

if  the  quantities  requested  are  not  available,  other  decisions  must  be  made,  the  request  may  be 
backordered  against  a  quantity  due  in  from  contract  or  from  arother  supply  source;  immediate 
procurement  may  be  initiated;  or  the  request  may  be  passed  to  another  supply  agency  that  can  fill 
the  need 

The  denial  rate  is  a  measure  of  the  compatibility  between  stock  records  at  the  ICP  and  materiel  on- 
hand  at  the  designated  depot.  A  denial  can  be  caused  by  inaccurate  recordkeeping  at  the  ICP  or 
depot,  improper  location  of  stock,  overshipment  on  previous  orders,  or  incorrect  inventory  practices 
at  the  depot  For  major  items,  supply  response  may  involve  overhaul  of  available  assets  m  unser¬ 
viceable  condition  or  assembly  of  requested  items  from  components  held  in  stock 


The  logistics  function  that  encompasses  packaging,  packing,  documenting,  and  release  of  mater, el 
for  transportation  to  receiving  activities  A  significant  portion  of  procurement  dollars  and  depot 
supply  operationa.  costs  go  for  preservation,  packaging,  packing,  unitizing  loads,  blocking,  and 
bracing  Different  modes  of  transportation  and  different  world  destinations  often  dictate  special 
packing  and  packaging  specifications 


D.4.b  Warehousing  (Depot  Operations). 

Within  the  warehousing  function,  two  special  requirements  must  be  addressed 
in  future  DLSS  procedures.  Within  the  DLSS  quality  assurance  standards,  better 
methods  of  recording,  updating,  and  labeling  shelf-life  information  must  be  included, 
in  accordance  with  DoD  4140. 27-M,  Identification,  Control,  and  Utilization  of  Shelf  - 
Life  Items.  Particularly  important  is  the  requirement  for  defining  methods  and 
procedures  for  automatic  and  recurring  notifications  from  the  ICP  IM  to  depot 
managers  of  approaching  shelf-life  end  dates,  along  with  the  depot  manager’s  own 
item  management  system  notification  requirements,  thus  avoiding  waste  and 
spoilage.  As  shelf-life  end  dates  approach,  the  materiel  accountability  records 
should  be  reviewed  on-line  by  the  ICP  IM  for  lateral  redistribution  considerations, 
through  the  retail  asset  visibility  capability,  previously  described  in  Section  D.2.c. 
Shelf-life  information  must  also  be  provided  on  shipment  documentation. 

The  second  special  area  for  MODELS  design  to  address  is  inclusion  of  haz¬ 
ardous  materiel  procedures  within  the  automated  receiving  and  storage  system. 
Hazardous  materiel  identification,  handling  and  storage,  and  shipping  procedures 
must  be  included  in  automated  recordkeeping,  either  as  a  part  of  the  DIDS  catalog 
information  or  in  depot-maintained  files  of  hazardous  materiel  data.  [Note:  the 
MODELS  project  team  must  review  ongoing  DoD  initiatives  in  hazardous  materiel 
information  interfaces  in  developing  its  conceptual  information  exchange  interfaces 
during  Phase  3  of  this  project.]  This  information  should  be  included  in  the  ware¬ 
house  system  for  on-line  access  by  both  stowing  and  shipping  personnel. 

MODELS  Requirement:  Modernized  DLSS  should  integrate 
DoD  4140. 27-M  for  shelf-life  items  and  hazardous  materiel 
procedures  into  an  expanded  wholesale  storage  standard. 


D.4.c  Physical  Inventory. 

The  DLSS  should  standardize  physical  inventory  procedures  throughout  DoD 
at  all  wholesale  and  retail  logistics  facilities  under  the  Physical  Inventory  Program 
(PEP).  These  procedures  should  encompass  the  following  functions  described  in 
Table  D-8  under  item  3.4.3,  Physical  Inventory: 

•  Physical  counting 

•  Reconciliation 

•  Causative  research 

•  Location  surveys 

•  Location  reconciliation. 

MODELS  Requirement:  The  MODELS  concept  must  include 
automated  processes  to  accommodate  and  improve  the  produc¬ 
tivity  of  conducting  these  procedures.  Bar-coding  technology 
must  be  accommodated  for  conducting  physical  inventory 
counts  and  location  surveys. 


D.4.d  Issue. 

Procedures  for  materiel  issue,  now  prescribed  in  both  MILSTRIP  and 
MILSTRAP,  should  be  consolidated  into  a  single  publication  encompassing  the  issue 
functions  described  in  Table  D-8.  The  procedures  should  also  standardize  record 
retention  periods,  by  record  type. 

The  MODELS  concept  should  consider  how  automated  interfaces  between  ICP 
and  depot  can  be  improved  to  (1)  provide  more  accurate,  timely  information  to  IMs 
concerning  issues  and  (2)  improve  customer  satisfaction  with  the  issue  process. 
Materiel  release  processing  would  be  combined  with  issue  posting  to  eliminate  pres¬ 
ent  problems  with  tracking  depot  actions  on  MROs  and  MRCs.  Issue  procedures 
should  include  the  reporting  of  depot  denials  through  the  ICP  to  the  requisitioner  as 
a  regular  requisition  status  followup.  Use  of  bar-coding  technology,  which  now 
offers  remote  posting  of  the  stock  available  data  base  as  materiel  is  picked,  would 


allow  for  synchronizing  drop  from  inventory  with  issue  actions  and  on-line  update  of 
accountable/custodial  records. 


MODELS  Requirement:  The  MODELS  concept  must  accom¬ 
modate  improved  automated  information  exchange  for  issue 
procedures  between  the  depot  and  ICP,  as  new  technologies 
such  as  bar-code  readers  are  introduced  into  depot  issue  pro¬ 
cessing. 

D.4.e  Shipment  Preparation. 

Procedures  for  materiel  shipment  preparation  are  now  prescribed  in 
MILSTRIP,  MILSTAMP,  and  the  MTMR.  They  include  procedures  for  consolidation, 
labeling,  and  documentation.  These  procedures  should  be  consolidated  into  a  single 
set  of  DoD-wide  shipment  preparation  procedures  whether  materiel  is  to  be  shipped 
within  CONUS,  overseas,  or  within  the  theater. 

Within  the  consolidation  function,  shipment  unit  identification  and  the 
capability  to  identify  specific  materiel  within  the  shipment  should  be  reviewed  and 
improved.  This  point  is  discussed  in  more  detail  in  tne  requirements  for  the 
Transportation  Function,  in  Section  E.3,  and  again  in  Part  II,  Sections  A. 3  and  A. 5. 
in  the  discussion  of  interfaces  between  Services  and  joint  activities. 

Bar  coding  and  EBDI  are  emerging  hardware  and  software  technologies  that 
will  have  a  significant  impact  on  both  DoD  and  the  commercial  transportation 
sectors. 


MODELS  ReQUirem^nt  Shipment  preparation  procedures 
should  all  be  integrated  in  modernized  DLSS  procedures.  I'he 
MODELS  concept  must  be  able  to  accommodate  the  full  extent 
of  information  exchange  requirements  dictated  by  integrated 
procedures.  The  MODELS  concept  must  also  allow  for  and 
encourage  the  use  of  har  coding  and  EBDI  standards  for 
improved  documentation  and  processing  efficiency 


VV>vV  v. 


D.5  Nonsupply  Interfaces. 

In  addition  to  the  supply  interfaces  covered  in  this  section,  MODELS  will 
require  integration  of  supply  with  other  major  logistics  functional  areas. 

The  interface  between  supply  and  procurement  is  largely  nonstandard  and  is 
often  manual.  MODELS  provides  an  opportunity  to  automate  and  standardize  many 
elements  of  the  acquisition  function,  in  addition  to  the  supply  interface. 

DLSS  now  cover  some  of  the  interfaces  between  Defense  Contract  Adminis¬ 


tration  Service  (DCAS)  functions  and  procurement  activities,  particularly  in 
MILSCAP.  Many  interfaces  with  supply,  transportation,  and  vendors/contractors 
could  be  automated  within  the  MODELS  concept  (see  the  earlier  discussion  under 
Acquisition  in  Chapter  C  of  this  part).  Paperless  interfaces  with  commercial  carriers 
and  vendors  using  EBDI  standards  are  possible.  This  topic  is  discussed  in  more 
detail  in  Part  II,  Section  B.2. 

MODELS  should  include  interfaces  with  (1)  programs  for  quality  assurance 
and  inspection  of  materiel  at  origin  or  destination,  (2)  depot  quality  programs,  and 
(3)  QDR  investigations.  Most  are  neither  integrated  nor  automated  but  they  should 
be.  Transportation  documentation  and  tracing  are  major  concerns  and  are  areas  for 
the  application  of  EBDI;  they  are  discussed  in  Part  II,  Section  A. 2. 

Present  DLSS  supply  concerns  in  R&M  are  transfer  to,  and  requisitioning 
from,  disposal.  Both  of  these  functional  elements  are  adopting  current  DLSS  stan¬ 
dards  prescribed  in  M3LSTRIP.  MODELS  should  improve  these  interfaces,  and 
provide  the  IM  with  visibility  of  assets  available  for  reutilization. 


CHAPTER  E.  TRANSPORTATION  FUNCTIONAL  REQUIREMENTS 


Military  transportation  and  commercial  for-hire  contract  transportation 
resources  exist  principally  to  move  people  and  things  from  where  they  are  to  where 
they  are  needed. 

Transportation  can  be  described  in  terms  of  (1)  a  requirement  to  move  some¬ 
thing,  that  must  be  supported  by  an  allocation  of  movement  capability  (authori¬ 
zation);  (2)  a  determination  of  the  manner  in  which  the  movement  will  take  place 
(traffic  management);  and  (3)  the  actual  movement.  All  three  of  these  functions  are 
affected  by  urgency  of  need,  method  of  movement  options  available,  carriers 
available,  costs,  packaging,  and  shipment  characteristics.  These  three  major 
functions  and  their  related  WBS  subfunctions  are  shown  in  Figure  E-ll,  and 
described  in  Table  E-9. 

The  MODELS  concept  will  address  the  movement  of  materiel  and  equipment 
only.  However,  moving  people,  including  both  individuals  and  groups  (such  as 
units),  is  recognized  as  an  important  aspect  of  the  defense  transportation  function. 
Since  specific  transportation  resources  can  be  utilized  interchangeably  for  moving 
people  or  materiel  and  equipment,  management  of  the  defense  transportation  func¬ 
tion’s  capability  (military  transportation  assets  and  commercial  for-hire  contract 
transportation  assets)  must  take  all  transportation  requirements  into  account. 

MODELS  Reauirement:  The  MODELS  concept  must  provide 
To 7  a  more  comprehensive  exchange  of  transportation  infor¬ 
mation/data  with  all  logistics  community  activities  and  also 
some  activities  that  are  not  included  in  the  defense  logistics 
operations/management  environment,  particularly  JCS,  the 
Joint  Deployment  Agency  (JDA),  and  the  Commanders-in- 
Chief(CINCs). 
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FIGURE  E-11.  TRANSPORTATION  FUNCTIONS 
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TABLE  E-9.  DESCRIPTIONS:  TRANSPORTATION  FUNCTIONS 


FUNCTIONS 

DESCRIPTIONS 

40 

Transportation 

The  activities  related  to  the  movement  of  personnel,  equipment,  and  supplies  m  support  of  military 
operations  or  other  requirements  It  includes  planning,  authorization,  routing,  scheduling,  and 
movement.  It  also  includes  procurement  of  these  services  from  commercial  or  other  sources 

4.1 

Authorization 

The  act  of  specifying  to  the  provider  of  transportation  the  requesting  organization  s  sanction  of  a 
specific  movement  requirement  Authorization  normally  includes  a  description  of  what  is  to  be 
moved,  the  origin,  the  destination,  the  priority,  and  a  fund  citation 

4.1  1 

Movement 

Requirement 

The  determination  that  it  is  necessary  for  an  organization  to  move  a  specified  number  of  personnel 
or  amount  of  material  between  two  or  more  locations 

4  1  2 

Priority 

Determination 

The  assignment  of  relative  importance  to  movement  requirements  Normally  accomplished  m 
accordance  with  established  rules,  general  or  specific 

4  1.3 

Funding 

The  act  of  designating  specific  authority  to  charge  the  cost  of  providing  transportation  to  an 
organization  in  some  cases,  such  as  the  utilization  of  internal  transportation  resources,  this  may 
not  be  an  overt  act  for  each  requirement  it  is  normally  a  specific  requirement  for  any  mter-Service 
transportation  support  and  the  procurement  of  commercial  transportation  support 

4.2 

Traffic 

Management 

The  planning,  routing,  scheduling,  and  control  of  personnel  and  material  movements,  including  the 
procurement  of  commercial  capability 

4  2.1 

Intra-Service/ 

Agency 

Traffic  management  activities  within  an  S/A  Decisions  and  procedures  are  governed  by  S/A  and 
jointly  established  policies  and  procedures 

4.2  2 

Inter-Service/ 

Agency 

Traffic  management  activities  that  involve  two  or  more  S/As  includes  development  of  joint  policies 
and  procedures. 

4  2  2  1 

Shipment 

Planning 

The  process  of  collecting  information  on  movement  requirements  and  evaluating  the  various 
factors  involved  in  satisfying  movement  requirements  in  the  most  economical  way  consistent  with 
UMMIPS  priorities  and  other  operational  considerations 

4  2  2  2 

Mode 

Selection 

The  process  that  results  in  a  decision  to  move  personnel  or  materiel  by  a  specific  type  of 
transportation  or  to  procure  the  services  of  a  travel  agent  or  freight  forwarder 

4  2  2.3 

Carrier 

Selection 

The  process  that  results  in  a  decision  to  move  personnel  or  materiel  by  a  specific  military  or  civilian 
operator  of  transportation  capability  The  operator  may  utilize  more  than  one  mode  to  accomplish 
a  specific  movement 

4  2  2  4 

Shipment 

Routing 

The  process  of  arriving  at  a  decision  to  execute  a  given  movement  over  a  specific  route  or 
combination  of  routes  This  may  be  a  traffic  management  decision  a  mode  operator  decision,  or  a 
combination  of  the  two  it  may  be  incorporated  into  the  selection  of  carrier  and  mode  decisions 

4  2.2  5 

Movement 

Monitoring 

The  process  of  tracking  a  specific  movement  Tracking  movements  range  from  determining  when  a 
shipment  arrives  at  a  destination  in  relation  to  its  scheduled  arrival  to  relatively  complex  reporting 
of  location  as  the  movement  proceeds  along  a  specific  route  in  accordance  with  a  prearranged 
schedule 

4  2  2  6 

Rerouting/ 

Diversion 

The  act  of  changing  the  routing  of  a  movement  or  changing  the  mode  or  earner  m  response  to 
some  unforeseen  requirement  or  to  overcome  unscheduled  delays  to  meet  the  original 
requirements  Includes  the  Select  mode,  Select  carrier,  and  Routing  decision  processes 

4  3 

Movement 

Activities  related  to  the  operation  of  transportation  modes  Includes  planning,  programming,  and 
budgeting  for  operation  of  transportation  resources,  such  as  trucks,  airplanes,  and  ships  and  the 
operation  of  modal  and  intermodal  terminals  Also  includes  procurement  of  similar  capabilities 
from  commercial  and  other  sources 

4  3  1 

Intra-Service/ 

Agency 

Activities  related  to  managmq  and  operating  transportation  within  an  S<A  Includes  procurement 
of  transportation  from  commercial  or  other  sources,  and  controls  for  reimbursement  of  industrially 
funded  transportation  activities 
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TABLE  E-9.  DESCRIPTIONS:  TRANSPORTATION  FUNCTIONS  (CONTINUED 


FUNCTIONS 

DESCRIPTIONS 

4  3  2 

Inter-Service/ 

Agency 

Activities  related  to  the  management  and  operations  of  transportation  where  two  or  more  S/As  are 
involved  Normally  refers  to  operation  of  the  T ransportation  Operating  Agencies  (TOAs)  providing 
common-user  transportation  support  to  all  DoD  customers  and  other  authorized  agencies  includes 
the  fiscal  controls  for  reimbursement  of  industrially-funded  TOA  activities 

4  3  2  1 

Mode 

Operations 

Planning,  programming,  budgeting,  and  operation  of  specific  modes  of  transportation  May 
include  modal  or  intermodal  terminal  operations  May  also  include  procurement  of  commercial  or 
other  modal  capability  to  augment  internal  capability 

4  3.2.1  1 

Air 

Operation  of  the  DoD  common-user  airlift  capability  and  procurement  of  commercial  or  other  aug 
mentation  to  this  capability  Includes  operation  of  common-user  aerial  ports  of  embarkation  ana 
debarkation  and  procurement  of  aerial  port  services 

4  3.2  1  2 

Sea 

Operation  of  the  DoD  common-user  sealift  capability  and  procurement  of  commercial  or  other  aug¬ 
mentation  of  this  capability  includes  procurement  of  terminal  services  under  certain  conditions 

43  2  1.3 

Truck 

In  theaters  of  operation,  the  operation  of  common-user  truck  transportation  or  procurement  of 
truck  transportation 

4  3  2  1  4 

Rail 

In  theaters  of  operation,  operation  of  common-user  rail  transportation  if  any.  or  procurement  o< 
rail  transportation 

4  3.2.1  5 

Pipeline 

In  theaters  of  operation,  operation  of  common-user  pipeline  transportation,  if  ary,  or  procurement 
of  pipeline  transportation  for  movement  of  fuel 

4  3.2.1  6 

Barge 

In  theaters  of  operation,  operation  of  common-user  barge  transportation  or  procurement  of  barge 
transportation 

4.3.22 

Terminal 

Operations 

Planning,  programming,  budgeting,  and  operation  of  transportation  terminals  May  be  modal,  but 
are  normally  intermodal  May  be  operated  by  a  modal  carrier  or  an  independent  organization 

4  3  2.2.1 

Receipt 

Activities  associated  with  unloading  and  checking  cargo 

4  3. 2.2.2 

Storage 

Activities  associated  with  temporary  retention  of  cargo  at  transportation  nodes  pending  further 
movement. 

4.3. 2.2.2 

Consolidation 

Collection  of  two  or  more  shipment  units  into  one  larger  shipment  unit  for  improved  movement 
efficiency  Also  includes  breakbulk  operations  in  delivery  areas 

4  3.2.2,4 

Outload 

Activities  associated  with  the  further  movement  of  cargo  and  recording  of  that  movement 

4  3  2  3 

Commercial 

Movement 

Procurement  of  transportation  services  from  commercial  or  other  sources  All  or  any  portion  of  a 
movement  may  be  procured,  and  the  services  procured  may  include  some  degree  of  traffic  manage¬ 
ment.  Does  not  include  procurement  of  transportation  capability  to  augment  internal  capability 
where  management  of  transportation  service  is  retained  by  an  S/A 

4  3  2  3.1 

Modal 

Carrier 

Activities  associated  with  shipping  by  commercial  modal  carrier,  m  accordance  with  traffic  manage¬ 
ment  decisions,  and  documenting  the  service  provided 

4  3  2  3  2 

Intermodal 

Carrier 

Activities  associated  with  shipping  by  commercial  intermodal  carrier,  in  accordance  with  traffic 
management  decisions,  and  recording  the  service  provided 

4  3  2  3  3 

Small 

Package  Carrier 

Activities  associated  with  shipping  by  small  package  carrier  (including  the  Postal  Service)  and 
recording  the  shipment,  if  required 

4  3  2  3  4 

Freight 

Forwarder 

Activities  associated  with  shipping  by  commercial  freight  forwarder  m  accordance  with  traffic 
management  decisions  and  recording  the  service  provided 

Transportation  support  for  the  DoD  falls  into  three  categories,  in-CONUS, 
overseas,  and  in-theater.  In-CONUS,  basic  procedural  transportation  guidance  is 
provided  by  the  MTMR,  MILSTAMP,  and  similar  Service  publications.  The  trans 
port  capability  for  CONUS  movements  is,  for  all  practical  purposes,  procured 
entirely  from  the  commercial  world.  The  MTMR  and  other  DoD  and  S/A  policies  and 
procedures  overlay  incompatible  commercial  documentation  and  data  requirements. 

The  DTS,  in  the  classic  sense  of  MILSTAMP  and  the  TOAs,  supports  the  second 
category  of  transportation,  DoD’s  international  transportation  requirements  (e.g., 
overseas  shipments).  The  DTS  is  composed  of  airlift  provided  by  the  Military  Airlift 
Command  (MAC),  sealift  provided  by  the  Military  Sealift  Command  (MSC)  and 
water-port  operations  provided  by  the  Military  Traffic  Management  Command 
(MTMC).  In  the  DTS,  the  military  is  the  major  operational  entity.  Some  military 
assets  are  used;  they  are  principally  MAC’S  air  cargo  capability,  MSC’s  very  limited 
military  sealift  capability,  and  a  few  military  terminals  and  ports.  Those  assets  are 
augmented  by  commercial  carrier  contracts  or  charters  for  ships  or  aircraft  to  be 
operated  under  military  operational  control.  When  the  overseas  movement  require¬ 
ment  is  offered  to  commercial  carriers  using  their  own  assets,  the  movement  of 
military  cargo  may  be  intermingled  with  that  of  commercial  cargo  (principally  by 
surface),  with  the  commercial  operator  being  in  operational  control  of  the  movement. 
DTS  management  procedures  are  predicated  on  MILSTAMP.  MILSTAMP  data  and 
documentation  requirements  are  not  always  effectively  interfaced  with  MTMR 
procedures  e.g.,  the  Government  Bill  of  Lading  (GBL)  stems  from  the  MTMR  not  the 
MILSTAMP,  and  they  overlay  commercial  procedures,  documentation,  and  data  in 
some  cases,  principally  sealift  and  water-port  operations. 


MODELS  Requirement:  The  MODELS  concept  must  provide 
for  a  reduction  of  paperwork  and  must  improve  the  flow  of  com¬ 
patible  data,  on  a  near-real-time  basis  in  some  cases,  within 
the  defense  transportation  function  and  to  and  from  other 
organizations,  including  commercial  carriers.  EBDI  concepts 
and  standards  must  be  incorporated.  (This  topic  is  discussed  in 
detail  in  Part  II,  Section  B.2.) 

The  third  category  of  DoD  transportation  is  that  provided  within  a  theater. 
Policies  and  procedures  vary  from  theater  to  theater,  reflecting  the  evolution  of  each 
theater.  Various  Service  policies  and  procedures  are  used,  as  well  as,  to  some  extent, 
MILSTAMP.  Transportation  capability  may  be  heavily  military.  However,  com¬ 
mercial  augmentation  is  frequently  used,  including  support  for  active  military 
operations  as  was  done  in  Vietnam. 

MODELS  Requirement:  The  DLSS-expanded  functions  must 
provide  for  evaluation  and  development  of  procedures  and  data 
exchange  requirements  in  theaters  of  operation,  compatible 
with  the  DTS  and  CONUS-based  activities  that  provide  trans¬ 
portation  data  to  the  theater  or  require  data  from  the  theater. 

Execution  of  these  simple  concepts  within  DoD  is  a  complex  process,  with  the 
complexity  stemming  from  two  major  factors:  myriad  heterogeneous  DoD  organi¬ 
zations  are  involved  in  the  total  transportation  function,  and  transportation  is  a 
support  function  for  both  strategic  and  tactical  operations  as  well  as  logistics 
operations.  A  contributing  factor  is  that  transportation  is  captive  (or  reactive)  to 
other  logistics  functions,  principally  supply,  and  strategic  and  tactical  decisions. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  evolutionary  development  of  a  near-real-time  capability  to 
provide  information  and  data  to  assist  MTMC  in  managing  the 
transportation  function  in  support  of  logistics  activities. 

E.l  Authorization. 

Authorization  for  transportation  is  a  S/A  responsibility.  Transportation  is  a 
response  to  requirements  for  movement,  requirements  that  are  established  by  the 
same  elements  of  the  S/As  that  under  OSD/JCS  guidance  also  establish  the  priorities 


for  movements.  Since  most  transportation  support  is  provided  by  commercial 
sources  or  the  industrially-funded  TOAs,  funding  is  one  element  in  the  decision 
process  leading  to  movement  authorization. 

During  crisis  or  wartime  conditions,  the  JCS  in  coordination  with  the  CINCs, 
become  responsible  for  authorizing  and  prioritizing  transportation  requirements, 
and  the  JDA  is  assigned  the  task  of  collecting  and  reporting  the  information 
required  for  JCS  decision-making.  This  function  and  JDA-supply-transportation 
information  issues  are  discussed  in  more  detail  in  Part  13,  Section  A. 5. 

E.2  Traffic  Management. 

Traffic  management  —  the  direction  (but  not  control)  and  monitoring  of  the 
movement  of  people  and  things  —  is  the  keystone  of  the  transportation  function. 
Most  transportation  policy  emanates  from  the  traffic  management  function.  The 
authorization  decision  process  is  often  dependent  upon  traffic  management  conti  ibu- 
tions,  such  as  service  (e.g.,  get  it  there  by  a  certain  time  or  at  a  reasonable  cost). 
Movement  (operation  of  the  modes  of  transportation)  is  reactive  to  traffic  manage¬ 
ment  decisions.  The  traffic  management  process  ranges  from  an  intuitive  decision  to 
move  something  in  a  certain  way  to  the  complex  process  of  planning  the  movement  of 
massive  amounts  of  materiel  (and  people)  from  many  origins  to  many  destinations, 
using  several  modes,  operators,  and  routes. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  continuing  improvements  in  the  exchange  of  data  between 
activities  engaged  in  the  authorization  decision  process  and 
the  traffic  management  function. 


In  its  purest  sense,  traffic  management  is  separate  and  distinct  from  move¬ 
ment.  In  DoD,  however,  these  two  functions  tend  to  merge  in  some  cases,  partic 
ularly  in  the  passenger  transportation  field.  The  separation  of  traffic  management 
and  movement  is  more  distinct  in  the  wholesale  logistics  area  than  at  the  operating 


levels  in  the  S/As.  The  real-world  merger  of  the  two  transportation  functions  should 
have  little  or  no  impact  on  the  MODELS  concept. 

Traffic  management  shares  with  movement  the  limelight  of  customer  visibil¬ 
ity.  When  customers  have  questions  or  problems  with  transportation,  shippers  turn 
to  traffic  management  with  their  demands  for  information  and  receivers  generally 
turn  to  operators.  Other  activities,  such  as  joint  and  S/A  headquarters,  may  turn  to 
either  or  both.  Shippers,  receivers,  and  the  many  other  activities  —  both  logistics 
and  other  organizations  —  concerned  with  transportation  management  support  have 
legitimate  needs  for  transportation  information  and  data.  However,  often,  the 
requester  does  not  speak  the  same  language  as  the  DoD  transportation  activity 
coordinators.  This  problem  is  addressed  in  Part  II,  Section  A. 3. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  a  reasonable  interchange  of  information  and  data  between 
transportation  activities  and  both  nontransportation  and  non¬ 
logistics  activities. 

E.3  Movement. 

The  movement  function  within  transportation  is  by  far  the  largest  and  most 
important  generator  of  transportation  information  and  data.  That  function  provides 
information  about  what  is  happening  or  has  happened  as  opposed  to  what  will 
happen. 

Most  of  the  information  generated  in  the  course  of  moving  materiel  is  of 
interest  only  to  the  activities  within  the  transportation  function.  For  example,  the 
amount  of  fuel  required  for  an  aircraft  is  of  little  interest  to  the  shippers  and 
receivers  of  the  cargo  the  aircraft  is  carrying.  Other  operational  information, 
however,  is  of  more  interest  to  the  customer.  For  example,  how  long  it  takes  to  fly 
from  point  A  to  point  B  may  be  of  some  limited  interest;  when  the  cargo  will  be 
delivered,  taking  into  account  loading/unloading,  processing,  and  other  time,  is  of 
prime  interest  to  the  customer. 


The  level  of  data  available  from  the  movement  subfunction  varies.  Usually  no 
record  is  made  of  shipments  sent  through  the  U.S.  Postal  Service.  However,  some 
movements,  such  as  those  requiring  a  signature  whenever  a  shipment  changes 
hands,  generate  a  great  deal  of  data. 

In  current  practice,  particularly  within  CONUS,  logistics  movements  are  made 
by  bill  of  lading  or  waybill  and  little  or  no  reporting  or  recording  of  movement  incre¬ 
ments  occurs.  Although  more  detailed  records  are  kept  in  the  DTS  [through  the  use 
of  Transportation  Control  and  Movement  Data  (TCMD)  and  Transportation  Control 
Numbers  (TCNs)  as  prescribed  by  MILSTAMP],  again  very  little  reporting  of 
movement  increments  takes  place.  Even  though  reporting  of  every  detail  is  not 
necessary,  recording  detail  and  having  it  available  when  required  is  important. 
Automated  recordkeeping  and  reporting  capabilities  must  expand  on  the  already 
existing  capabilities  to  trace  and  report,  when  required,  the  location  of  items,  both 
individually  (for  critical/protected  cargo)  and  collectively.  These  are  the  require¬ 
ments: 

•  The  level  of  detail  in  reports  should  be  kept  as  low  as  is  operationally 
feasible 

•  Exception  reporting  should  be  the  rule 

•  Communications  requirements  must  be  considered,  particularly  in  crisis 
and  wartime 

•  Reporting  requirements  should  be  based  on  data  that  are  generated  by 
transportation  operations,  not  data  that  are  produced  solely  for  reporting 
purposes 

•  User-friendly,  common  language  terminology  rather  than  ADP  language, 
must  be  used  to  respond  to  users’  requirements. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  improving  existing  capabilities  for  recording  and  reporting 
of  transportation  movement  information  and  data. 


CHAPTER  F.  REUTILIZATION  AND  MARKETIN'! , 


This  function  encompasses  reutilization,  sale,  or  disposal  by  Mth*-r  m*  ,i.\  : 

DoD  excess  and  surplus  property.  Present  DLSS  procedures  in  MILSTRIP  lOrtr*- 
ing  this  function  are  confined  to  shipment  to  and  requisitioning  from  1)RM<  )s  I  h«- 
functions  actually  encompassed  by  DRMOs  are  to  receive,  process  ■  rur 
distribute,  market,  and  dispose  of  excess/surplus  military  property.  An  additional 
capability  to  be  added  to  this  list  —  and  one  critical  to  the  cost-effective  accomplish 
ment  of  the  other  functions  —  is  item  visibility.  These  DRMO  functions  are  shown  in 
Figure  F-12  and  described  in  Table  F-10. 

DRMS  is  headquartered  in  Battle  Creek,  Michigan,  and  its  worldwide  network 
of  more  than  130  DRMOs  and  more  than  80  off-site  branches  receives  approximately 
3  million  excess  items  annually  valued  at  almost  $5  billion.  Approximately 
16  percent  (about  500,000)  items  are  disposed  of  through  reutilization,  25  percent  are 
sold,  and  the  remaining  ones  are  either  downgraded  to  scrap  and  sold,  abandoned,  or 
destroyed. 

F.l  Item  Visibility. 

A  major  objective  of  the  reutilization  function  is  item  (asset)  visibility  to 
achieve  the  most  cost-effective  utilization  of  excess/surpius  materiel.  The  DRMOs 
should  be  major  sources  of  supply  for  DoD  retail  customers  and  a  source  of  replenish 
ment  for  wholesale  IMs.  The  reutilization  function  has  a  series  of  standardized, 
automated  procedures  for  wide  dissemination  of  descriptive  information  on  its 
available  assets.  Manual  lists  are  also  disseminated  on  a  weekly  basis  to  approxi¬ 
mately  5,000  customers. 

I 

i 


FIGURE  F-12.  DEFENSE  REUTIUZATION  AND  MARKETING  FUNCTIONS 


An  on-line  Interrogation  Requirements  Information  System  (IRIS)  covering 
the  full  spectrum  of  items  currently  available  greatly  improves  this  process  and 
raises  the  level  of  materiel  and  equipment  reutilization. 
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TABLE  F- 10.  DESCRIPTIONS.  REUTILIZATION  AND  MARKETING  FUNCTIONS 


FUNCTIONS 

DEFINITIONS 

60 

Realization 
and  Marketing 

The  logistics  processes  associated  with  receipt,  classification,  storage,  reutilization.  sale,  or 
disposal  of  property  excess  to  supply  requirements 

6  1 

Item  Visibility 

The  electronic  visibility  of  materiel  assets  declared  excess  withm  the  DoD  supply  system, 
including  such  pertinent  information  as  quantity,  location,  condition  and  sim  ar  qata  as  s 
necessary  to  fully  describe  the  materiel  to  a  potential  reguisitioner 

6  2 

Reutilization 

The  process  that  ensures  that  excesses  from  one  DoD  Component  are  scree neo  ana  „t  nzed  ’o 
the  fullest  extent  practicable  by  other  DoD  Components  or  other  -ederal  agencies  screening 
activities  take  into  account  the  cost  of  packaging,  crating,  handling  transporta'ion  ana 
rehabilitation  to  preclude  uneconomical  transfer  when  compared  with  the  cost  ana  eaat me 
involved  m  new  procurement 

6  3 

Sale 

If  excess  materiel  cannot  be  reused  within  DoD  or  other  governmental  or  nonprofit  organiza¬ 
tions.  the  residual  is  sold  Sales  and  merchandising  responsibility  rests  with  'he  Defense 
Reutilization  and  Marketing  Regions  Those  regions  receive  reports  of  assets  located  n 
various  DRMOs,  maintain  property  accountability,  determine  types  of  sales  to  be  conduced 
and  handle  merchandising  response 

6  4 

Scrap  and  Waste 

When  property  is  not  utilized,  donated,  or  sold,  t  may  be  offered  as  scrap  ana  waste  mater  ei 
at  public  sale  to  the  highest  bidder  These  are  national  auctions  for  'arge  quantities  of  accu¬ 
mulated  scrap 

F.2  Reutilization. 

Reutilization  of  assets  requires  close  cooperation  with  IMs  and  procurement 
activities.  To  maximize  reutilization  opportunities  for  IMs  and  procurement,  the 
DRMS  inventory  is  available  through  on-line  access.  The  files  are  checked  before 
procurement  of  new  stock  begins. 

F.3  Sale. 

A  recognized  problem  in  the  sale  process  is  accurate  and  timely  reporting  of  the 
condition  of  an  asset.  DRMS  assets  are  normally  retained  for  6  months  and  in  some 
instances,  a  year.  The  published  lists  of  available  items  consist  of  descriptions  and 
the  NSN  when  it  is  known.  Another  problem  is  that  the  condition  of  an  item  may 
change  over  time,  and  the  condition  code  is  not  easily  updated  in  current  systems. 
Again,  asset  visibility  is  an  important  factor  in  obtaining  the  best  sale  price. 


F.4  Scrap  and  Waste. 

If  no  useful  purpose  can  be  found  for  an  item,  it  is  downgraded  to  scrap,  and  the 
scrap  is  disposed  of  through  sales  or  service  contracts.  This  process  requires  main¬ 
tenance  of  auditable  accounting  records.  Standard  procedures  for  various  types  of 
items  (classified,  hazardous)  must  be  carefully  followed  and  reported  through  stan¬ 
dard  transactions. 

F.5  Disposal  Automation. 

Much  of  the  automation  to  provide  on-line  access  to  excess/surplus  items  is 
already  in  progress  through  the  DAISY  project.  The  DRMS  function  and  its  DAISY 
project  are  the  responsibility  of  DLA.  Since  the  DRMS  function  is  an  integral  DoD- 
wide  logistics  activity  with  multiple  DLSS  interfaces,  close  coordination  must  be 
maintained  between  the  DAISY  project  office  and  the  MODELS  project  office. 
Because  of  the  integrated  relationships  between  many  DRMS  and  DLSS  functions, 
OSD  should  consider  a  closer  working  relationship  between  the  responsible  organi¬ 
zations. 


MODELS  Requirement:  The  MODELS  concept  must  recognize 
the  integral  role  of  DRMS  in  the  total  logistics  process  and 
should  interface  into  the  MODELS  conceptual  design  an  evolv¬ 
ing  DAISY  capability  for  on-line  visibility  of  excess  assets. 
Asset  visibility  should  be  available  to  wholesale  IMs  and  all 
retail-level  supply  echelons.  OSD  should  consider  the  integra¬ 
tion  of  DRMS  functional  procedures  into  the  DLSS  scope  of 
responsibility. 


CHAPTER  G.  SUMMARY  OF  PART  I  MODELS  REQUIREMENTS 


The  previous  six  chapters  presented  more  than  60  data  exchange  and  logistics 
functional  requirements  to  be  incorporated  into  modernized,  expanded  DLSS  and  to 
improve  information  exchange,  through  the  use  of  modern  communications  tech¬ 
niques  and  technologies. 

To  assist  in  reviewing  the  magnitude  of  these  requirements,  this  chapter  pre¬ 
sents  all  the  Parti  requirements  in  a  sequential  list.  The  section  title  for  the 
requirement  is  listed  along  with  the  page  number  in  the  text  to  facilitate  referral  to 
the  rationale  for  a  specific  requirement. 


A.  SCOPE  OFTHE  MODERNIZED  DEFENSE  LOGISTICS  STANDARD 

SYSTEMS  FUNCTIONAL  ACTIVITIES. 

MODELS  Requirement:  Informational  inputs  and  function-to- 
function  interfaces  (for  example,  supply-to-transportation) 
should  be  reevaluated  and  redefined  to  overcome  known  inter- 
S/A  information  deficiencies  not  addressed  by  the  current 
DLSS  and  to  meet  the  needs  of  new  and  expanding  functional 
and  management  information  requirements.  (Parti,  Chap¬ 
ter  A,  page  1-6) 

A.l  DLSS  Transactions  and  Data  Exchange  Considerations. 

MODELS  Requirement:  The  MODELS  conceptual  design 
must  provide  flexible  transaction  formats  and  a  methodology 
for  expedited  adoption  of  new  codes  and  procedures  as  logistics 
operations  and  management  information  needs  change.  (This 
characteristic  is  discussed  in  more  detail  in  Part  II,  Sec¬ 
tion  B.2)  (Parti,  Chapter  A,  Section  A.l,  page  1-8) 

MODELS  Requirement:  UMMIPS  performance  measurement 
standards  and  procedures  should  become  part  of  the  restruc¬ 
tured,  expanded  DLSS,  and  must  continue  to  be  closely 
coordinated  with  the  Joint  Chiefs  of  Staff  (JCS)  for  FAD  and 
priority  assignments.  (This  requirement  is  discussed  in  more 
detail  in  Parti,  Chapter  C.)  (Parti,  Chapter  A,  Section  A.l, 
page  1-8) 
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MODELS  Requirement:  MODELS  will  require  some  degree  of 
data  base  and  data  model  standardization.  (Parti,  Chapter  A, 
Section  A.l,  page  1-9) 

MODELS  Requirement:  The  MODELS  concept  must  provide 
the  capability  for  internal  S/A-unique  data  needs  to  be  accom¬ 
modated  in  DLSS  inter-S/A  transactions.  (Parti,  Chapter  A, 
Section  A.l,  page  I- 10) 

MODELS  Requirement:  MODELS  transaction  formats  must 
provide  flexibility  to  handle  two-party  and  multi-party  infor¬ 
mational  exchanges,  even  though  not  formally  part  of  DLSS 
procedures.  (Part  I,  Chapter  A,  Section  A.l,  page  1-11) 

MODELS  Requirement:  A  standard  DoD  logistics  data  ele- 
ments  dictionary  will  be  a  requisite  (and  a  responsibility  of  the 
DLSS);  it  will  have  to  include  all  data  elements,  terms,  and 
definitions  used  in  S/A  logistics  system  interfaces  and  infor¬ 
mation  exchanges.  The  basis  for  this  dictionary  should  be 
LOGDESMAP.  (Part  I,  Chapter  A,  Section  A.l,  page  1-11) 

A.2  Requirements  Drivers. 

MODELS  Requirement:  Modernized  DLSS  must  provide  for 
standardization  of  retail  procedures.  (Parti,  Chapter  A,  Sec¬ 
tion  A.2,  page  1-12) 

MODELS  Requirement:  The  MODELS  concept  must  coordi- 
nate  with  all  S/A  logistics  modernization  requirements.  It 
must  also  be  able  to  satisfy  logistics  information  requirements 
and  fully  support  resupply  requirements  in  crisis  or  wartime 
situations.  (Parti,  Chapter  A,  Section  A.2,  page  1-13) 

A.3  Logistics  Interfaces. 

MODELS  Requirement:  The  MODELS  conceptual  design 
should  accommodate  all  information  exchanges  between  inter- 
S/A  logistics  functions  and  operational/management  compo¬ 
nents.  (Part  I,  Chapter  A,  Section  A.3,  page  1-13) 
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PERFORMANCE  MEASUREMENT  FUNCTIONAL  REQUIREMENTS. 


MODELS  Requirement:  The  MODELS  concept  should  include 
the  capability  to  (1)  accumulate  performance  characteristic 
data  generated  as  a  normal  process  of  daily  operations,  and 
(2)  provide  for  the  retrieval  of  performance  data  in  a  form  that 
the  intended  recipient  will  find  most  useful.  This  capability 
should  include  collection  of  data,  based  on  normally  generated 
operations  data  (not  special  data  collection  efforts),  and  rapid 
retrieval  in  easily  modified  formats,  to  view  information  from 
different  points  of  interest.  (Parti,  Chapter  B,  page  1-16) 

B.l  Retail  Inventory  Management. 

MODELS  Requirement:  The  MODELS  concept  should  include 
methods  for  collecting  and  reporting  data  at  the  retail  opera¬ 
tions  level  to  satisfy  a  variety  of  performance  measurement 
criteria.  (Parti,  Chapter  B,  Section  B.l,  page  1-17) 

B.2  Wholesale  Inventory  Management. 

MODELS  Requirement:  The  MODELS  concept  design  should 
make  it  easy  to  measure  the  performance  of  a  range  of  opera 
tions  and  trend  indicators  at  the  wholesale  operations  level. 
(Parti,  Chapter  B,  Section  B.2,  page  1-23) 

B.3  Pipeline  Performance. 

MODELS  Requirement:  The  MODELS  concept  should  identify 
methods  and  procedures  to  collect  pipeline  performance  mea 
surement  data  at  each  segment  of  the  process  as  it  occurs.  The 
DLSS  should  standardize  the  definition  of  each  pipeline  seg 
ment.  (Parti,  Chapter  B,  Section  B.3,  page  1-24) 

MODELS  Requirement:  The  MODELS  concept  must  have  the 
capability  to  electronically  collect,  collate,  and  summarize  dis 
crepancy  reports  from  all  S/A  organizations  worldwide  as  one 
element  of  performance  measurement  reporting.  These 
discrepancy  reporting  evaluation  procedures  should  be  incor 
porated  into  DoD-wide  standard  performance  measures. 
(Part  I,  Chapter  B,  Section  B.3,  page  1-24) 


B.4  Contracting 


MODELS  Requirement:  The  DLSS  should  develop  standard 
criteria  for  measuring  procurement  and  contracting  perfor¬ 
mance.  The  MODELS  concept  must  include  procedures  to 
collect  these  standardized  performance  measurement  data  as  a 
normal  function  of  procurement  and  contract  administration 
process  information  flows.  (Parti,  Chapter  B,  Section  B.4, 
page  1-26) 

B.5  Interfund  Billing. 

MODELS  Requirement:  The  MODELS  concept  should  include 
the  development  of  methods  toward  modernizing  the  capability 
to  accomplish  the  interfund  billing  procedures  without  the 
current  cost.  (Part  I,  Chapter  B,  Section  B.6,  page  1-26) 

B.6  Weapons  System  Management. 


MODELS  Requirement:  Modernized  DLSS  procedures  must 
define  a  standard  weapons  system  performance  measurement 
program,  including  standardized  weapons  system  identifica¬ 
tion  codes  in  all  applicable  transactions.  The  DLSS  procedures 
must  allow  for  multiple  weapons  system  coding  for  common- 
use  items.  The  MODELS  design  must  provide  the  automated 
capabilities  to  perform  weapons  system-oriented  performance 
measurement  of  logistics  operations.  This  must  include  access 
by  weapons  system  relationships  to  wholesale  and  retail  opera¬ 
tional  performance  measurement  data.  (Parti,  Chapter  B, 
Section  B.6,  page  1-28) 

MODELS  Requirement:  A  comprehensive  set  of  logistics 
operations  performance  measurements  should  be  developed 
and  implemented  through  a  DLSS  procedural  publication. 
(Parti,  Chapter  B,  Section  B.6,  page  1-29) 

ACQUISITION  FUNCTIONAL  REQUIREMENTS. 

C.I  Procurement  Activities. 


MODELS  Requirement:  The  modernized  DLSS  procedures 
should  encompass  standard  procurement  functions,  contract 
modifications,  and  related  inter-S/A  information  exchange 
requirements.  (Part  I,  Chapter  C,  Section  C.I,  page  1-35) 
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C.2  Contract  Administration  Activities. 
C.2.a.  MILSCAP  Transactions. 


MODELS  Requirement:  MODELS  acquisition  function  trans- 
action  formats  must  be  variable  in  length  to  accommodate  all 
S/A  contract  data  exchange  requirements.  All  procurement 
and  contract-related  information  should  be  available  electron¬ 
ically.  (Part  I,  Chapter  C,  Section  C.2. a,  page  1-37) 

C.2.c.  Technical  Administration. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
access  to  contract  data  via  various  data  elements  and  also 
establish  and  maintain  relationships  among  data  elements 
through  a  well-designed  data  architecture.  (Parti,  Chapter C, 
Section  C.2.c,  page  1-38) 

C.2.e.  Quality  Assurance. 

MODELS  Requirement:  CDRs  should  become  a  part  of  ACO/ 
PCO  data  bases  and  should  be  available  on-line.  (Parti, 
Chapter  C,  Section  C.2.e,  page  1-39) 

C. 3  Technical  Data  Acquisition. 

MODELS  Requirement:  The  MODELS  effort  should  continue 
to  closely  monitor  CALS  developments  and  information 
exchange  protocols  and  procedures.  As  standards  are 
developed  by  the  OSD-CALS  Group  for  technical  data  acquisi 
tion  and  distribution  procedures  and  communications  inter 
faces,  these  standards  should  be  published  as  part  of  the 
modernized  DLSS  technical  data  functions  discussed  here  and 
in  Parti,  Section  D. 3.  (Parti,  Chapter  C,  Section  C.3, 
page  1-40) 

SUPPLY  FUNCTIONAL  REQUIREMENTS. 

D. I  Retail  Requisitioning. 

D.I.a  Requisitions. 

MODELS  Requirement .  Retail  requisitioning  should  be  DLSS 
compatible  throughout  the  S/A  logistics  community.  DLSS 
procedures  should  standardize  the  requisitioning  transaction 
to  accommodate  retail-level  end  user  requirements.  (Parti, 
Chapter  D,  Section  D. l.a,  page  1-48) 
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MODELS  Requirement:  The  MODELS  concept  should  provide 
retail  users  with  direct,  on-line  access  to  retail  supply  echelons 
within  their  supply  issue  hierarchy  and  then  to  the  wholesale 
logistics  systems  for  inquiries  about  stock  availability,  identi¬ 
fication  of  retail-issue  requisition  demand  and  shipment 
actions.  (Part  I,  Chapter  D,  Section  D.l.b,  page  1-49) 


D.l.c  Receipt  Take-Up  and  Acknowledf 


MODELS  Requirement:  The  MODELS  concept  must  recognize 
the  usefulness  of  bar  coding  for  the  receipt  take-up  and 
acknowledgment  process  and  must  include  DLSS  procedures 
for  accessing  due-in  posted  data,  using  bar-coding  techniques, 
with  automated  receipt  posting  and  reporting.  (Parti, 
Chapter  D,  Section  D.l.c,  page  1-49) 


D.l.d  Discrepancy 


sorting  and  Processing 


MODELS  Requirement:  The  MODELS  implementation 
should  encourage  automating  all  types  of  discrepancy/defi¬ 
ciency  recordkeeping  and  propose  procedures  for  automated 
response  and  disposition  instruction  processing,  in  accordance 
with  integrated  standards  published  in  modernized  DLSS  pro¬ 
cedures.  (Parti,  Chapter  D,  Section  D.l.d,  page  1-50) 


MODELS  Requirement:  The  modernized,  expanded  DLSS 
should  standardize  processing  of  materiel  and  equipment  to 
DRMO’s,  including  all  types  of  local  turn-ins.  The  automated 
processing  of  materiel  to  R&M  functions,  even  for  local  turn- 
ins,  should  be  interfaced  with  MODELS  implementation. 
(Parti,  Chapter  D,  Section  D.l.e,  page  1-51) 


D.l.f  Shipments. 


MODELS  Requirement:  Procedures  for  all  retail  shipment 
preparation  and  documentation  should  be  incorporated  into 
the  modernized  DLSS.  (Parti,  Chapter  D,  Section  D.l.f, 
page  1-51) 
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D.2  Wholesale  Inventory  Management. 


D.2.a  Requirements  Computation  and  Acquisition. 

MODELS  Requirement:  The  expanded  DLSS  must  develop 
DoD-staudardi-Jor-analysis  of  demand  and  presentation  of 
requirements  data,  including  initial  provisioning  procedures 
and  the  control  and  management  of  war  reserve  materiel 
requirements.  (Part  I,  Chapter  D,  Section  D.2. a,  page  1-56) 

D.2.b  Cataloging. 

MODELS  Requirement:  The  MODELS  concept  should  review 
DIDS  modernization  requirements  and  plans  and  closely 
coordinate  the  MODELS  conceptual  design  to  accommodate 
future  DIDS  capabilities.  (Parti,  Chapter  D,  Section  D.2. b, 
page  1-57) 

D.2.c  Inventory  Control. 

MODELS  Requirement:  All  inventory  management  and  con¬ 
trol  issues  and  procedures  should  be  integrated  in  an  expanded 
DLSS.  Within  this  integrated  environment,  the  MODELS 
design  must  provide  the  IMM  the  capability  for  on-line  DoD- 
wide  asset  visibility.  (Parti,  Chapter  D,  Section  D.2. c, 
page  1-58) 

D.2.d  Distribution  and  Redistribution. 

MODELS  Requirement:  Distribution  and  redistribution  proce- 
dures  should  be  consolidated  under  one  expanded  DLSS  proce¬ 
dure  for  wholesale  supply  management.  (Part  I,  Chapter  D, 
Section  D.2.d,  page  1-59) 

D.2.e  Repair  and/or  Rebuild. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
an  automated  information  interface  for  maintenance  require¬ 
ments.  The  modernized  DLSS  must  provide  for  the  induction 
and  return  of  reparables,  so  that  the  IMM/IM  (owning)  has  the 
necessary  asset  visibility  to  allow  for  proper  control,  and  to 
take  asset  status  into  consideration  when  performing  procure¬ 
ments  and  redistributions.  (Parti,  Chapter  D,  Section  D.2.e, 
page  1-60) 
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D.2.f  Requisition  Processing. 

MODELS  Requirement:  Requisition  history  retention  periods 
for  each  type  of  transaction  should  be  standardized.  Visibility 
of  referrals,  backorders,  depot  denials,  and  cancellations 
should  be  enhanced.  (Parti,  Chapter  D,  Section  D. 2. f, 
page  1-60) 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  correct  response  of  the  logistics  system  to  JCS  and  Unified 
Command  allocation  guidance.  (Parti,  Chapter D,  Sec¬ 
tion  D.2.f,  page  1-60). 

MODELS  Requirement:  The  use  of  priority  codes,  project 
codes,  and  weapons  system  codes  in  the  requisition  transaction 
must  be  defined  and  accommodated  in  the  MODELS  concept. 
Requisition  edits  by  the  supply  source  and  intervening  third 
parties  (such  as  DAAS)  need  to  be  integrated  under  the  DLSS. 
(Parti,  Chapter  D,  Section  D.2.f(l),  page  1-61) 

MODELS  Requirement:  MODELS  should  provide  a  better 
approach  to  accessing  source-of-supply  information  and  to 
resolving  conflicts.  (Parti,  Chapter  D,  Section  D.2.f(2), 
page  1-61) 

MODELS  Requirement:  MODELS  must  establish  standards 
for  methods  of  supply  determination  processes  to  assure 
responsive  support  of  user  requirements.  (Parti,  Chapter  D, 
Section  D.2.K3),  page  1-61) 

MODELS  Requirement :  The  MODELS  concept  should  include 
a  method  for  providing  denial  status  directly  to  requisitioners 
either  at  a  retail-supply  point  or  through  the  retail-supply 
point  system  to  end-user  requisitioners.  Standardized  proce 
dures  and  time  frames  are  needed  to  improve  data  retention  for 
depot  records  and  for  the  use  of  constructive  delivery-and- 
receipt  concepts  for  billing  purposes  throughout  all  levels  of 
the  logistics  community.  (Parti,  Chapter D,  Section D. 2. f(4), 
page  1-62) 

MODELS  Requirement:  MODELS  should  evaluate  the 
continuing  need  for  pushed  follow-ups,  especially  to  update 
centralized  data  bases  maintained  by  the  S/As,  if  interactive 
inquiry  gateway  capability  is  established  throughout  the  logis¬ 
tics  system  network.  This  change  would  require  that  stan¬ 
dardized  procedures  and  guidelines  be  promulgated  for  inquiry 
capability.  (Part  I,  Chapter  D,  Section  D.2.fT5),  page  I  63) 
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MODELS  Requirement:  MODELS  must  incorporate  improved 
interface  capabilities  to  permit  timely  processing  of  modifica¬ 
tions  and  cancellations.  Also,  modernized  DLSS  must  include 
procedures  and  standard  rules  concerning  the  stages  at  which 
changes  can  be  made  (during  which  segments  of  the  pipeline 
process),  what  changes  are  authorized  with  various  modes  of 
data  access  (interactive  versus  transactional),  and  who  is 
authorized  to  initiate  interactive  changes,  taking  appropriate 
precautions  on  access  and  record-level  security.  (Parti, 
Chapter  D,  Section  D.2.f\7),  page  1-64) 

MODELS  Requirement:  DLSS  guidelines  and  procedures  for 
processing  backorder  releases  need  to  be  developed  and  imple 
mented.  A  priority  processing  scheme  similar  to  that  used  for 
in-process  requisitions  should  be  applied  to  backorder  release 
processing.  Partial  shipments  of  priority  materiel  should  be 
considered,  and  rules  and  automated  procedures  should  be 
developed  to  standardize  when  such  shipments  can  be  autho¬ 
rized  and  by  whom.  (Parti,  Chapter  D,  Section  D. 2. f(8), 
page  1-65) 

D.2.g  Retail  Excess  Processing  (Returns). 

MODELS  Requirement:  MODELS  must  improve  IM  visibility 
of  retail  excess  materiel.  Also,  the  DLSS  should  identify  proce 
dures  to  integrate  retail  returns  with  discrepancy  processing 
systems.  (Parti,  Chapter  D,  Section  D.2.g,  page  1-65) 

D.2.h  Wholesale  Excessing. 

MODELS  Requirement:  Procedures  for  ICP  determination 
and  processing  of  wholesale  excess  materiel  need  improve¬ 
ment.  (Parti,  Chapter  D,  Section  D.2.h,  page  1-66) 

D.2.i  Discrepancies. 

MODELS  Requirement:  The  DLSS  should  define  a  standard 
set  of  reporting  procedures  for  all  types  of  discrepancies,  in  one 
procedural  document.  The  MODELS  concept  should  consider 
methods  for  automated  integration  of  deficiency  reporting 
procedures  through  data  base  techniques  and  on-line,  inter 
active  information  retrieval  capabilities.  (Parti,  Chapter  D, 
Section  D.2.i,  page  1-67) 
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D.3  Technical  Data  Management. 

D.3.a  Use  and  Management  of  Technical  Data. 

MODELS  Requirement:  DLSS  procedures  need  to  be  devel- 
oped  to  define  standards  for  the  use  and  transmission  of 
technical  data.  The  MODELS  design  must  allow  and  promote 
on-line  access  to  catalog  and  technical  data,  with  full  graphics 
capability  for  transmission  and  display  of  digitized  images. 
This  capability  must  incorporate  CALS-developed  procedure 
and  protocol  standards  as  discussed  in  Parti,  Section  C. 3. 
(Part  I,  Chapter  D,  Section  D.3. a,  page  1-68) 

MODELS  Requirement:  The  MODELS  concept  should  provide 
for  standardization  of  procedures  for  the  exchange  of  technical 
data  between  the  S/As.  (Parti,  Chapter D,  Section  D.3. a, 
page  1-70) 

D.3.b  Cataloging. 

MODELS  Requirement:  The  DLSS  must  provide  for  standard- 
ization  of  cataloging  activities  related  to  technical  data, 
engineering  drawings,  and  documents,  in  accordance  with  the 
OSD-CALS  Group  recommendations.  (Parti,  Chapter D,  Sec¬ 
tion  D.3.b,  page  1-70) 

D.3.c  Storage  and  Retrieval. 

MODELS  Requirement:  The  DLSS  should  incorporate  the 
findings  and  recommendations  of  the  CALS  project  for  tech 
nical  data  storage  and  retrieval  standardized  procedures. 
(Part  I,  Chapter  D,  Section  D.3.c,  page  1-72) 

D.4  Wholesale  Storage. 

D.4.a.  Receipt. 

MODELS  Requirement:  Wholesale  receipt  procedures  for 
information  access  and  exchange  between  the  depot  and  ICP 
should  be  fully  covered  under  the  modernized  DLSS,  including 
use  of  bar-coding  technology,  interface  requirements  to  other 
logistics  functions,  and  performance  measurement/quality 
control  processes.  (Part  I,  Chapter  D,  Section  D.4. a,  page  1-74) 
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D.4.b.  Warehousing  (Depot  Operations). 

MODELS  Requirement:  Modernized  DLSS  should  integrate 
DoD  4140.27-M  for  shelf-life  items  and  hazardous  materiel 
procedures  into  an  expanded  wholesale  storage  standard. 
(Part  I,  Chapter  D,  Section  D.4.b,  page  1-76) 

D.4.c.  Physical  Inventory. 

MODELS  Requirement:  The  MODELS  concept  must  include 
automated  processes  to  accommodate  and  improve  the  produc¬ 
tivity  of  conducting  these  procedures.  Bar-coding  technology 
must  be  accommodated  for  conducting  physical  inventory 
counts  and  location  surveys.  (Parti,  Chapter  D,  Section  D.4.c, 
page  1-77) 

D.4.d.  Issue. 

MODELS  Requirement:  The  MODELS  concept  must  accom¬ 
modate  improved  automated  information  exchange  for  issue 
procedures  between  the  depot  and  ICP,  as  new  technologies 
such  as  bar-code  readers  are  introduced  into  depot  issue 
processing.  (Part  I,  Chapter  D,  Section  D.4.d,  page  1-78) 

D.4.e.  Shipment  Preparation. 

MODELS  Requirement:  Shipment  preparation  procedures 
should  all  be  integrated  in  modernized  DLSS  procedures.  The 
MODELS  concept  must  be  able  to  accommodate  the  full  extent 
of  information  exchange  requirements  dictated  by  integrated 
procedures.  The  MODELS  concept  must  also  allow  for  and 
encourage  the  use  of  bar  coding  and  EBDI  standards  for 
improved  documentation  and  processing  efficiency.  (Parti, 
Chapter  D,  Section  D.4.e,  page  1-78) 

E.  TRANSPORTATION  FUNCTIONAL  REQUIREMENTS. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  a  more  comprehensive  exchange  of  transportation  infor 
mation/data  with  all  logistics  community  activities  and  also 
some  activities  that  are  not  included  in  the  defense  logistics 
operations/management  environment,  particularly  JCS,  Joint 
Deployment  Agency  (JDA),  and  the  Commanders-in  Chief 
(CINCs).  (Part  I,  Chapter  E,  page  1-81) 
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MODELS  Requirement:  The  MODELS  concept  must  provide 
for  a  reduction  of  paperwork  and  must  improve  the  flow  of  com¬ 
patible  data,  on  a  near-real-time  basis  in  some  cases,  within 
the  defense  transportation  function  and  to  and  from  other 
organizations,  including  commercial  carriers.  EBDI  concepts 
and  standards  must  be  incorporated.  (This  topic  is  discussed  in 
detail  in  Part II,  Section  B.2.)  (Parti,  Chapter E,  page  1-86) 

MODELS  Requirement:  The  DLSS-expanded  functions  must 
provide  for  evaluation  and  development  of  procedures  and  data 
exchange  requirements  in  theaters  of  operation,  compatible 
with  the  DTS  and  CONUS-based  activities  that  provide  trans¬ 
portation  data  to  the  theater  or  require  data  from  the  theater. 
(Part  I,  Chapter  E,  page  1-86) 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  evolutionary  development  of  a  near-real-time  capability  to 
provide  information  and  data  to  assist  MTMC  in  managing  the 
transportation  function  in  support  of  logistics  activities. 
(Part  I,  Chapter  E,  page  1-86) 


MODELS  Requirement:  The  MODELS  concept  must  provide 
for  continuing  improvements  in  the  exchange  of  data  between 
activities  engaged  in  the  authorization  decision  process  and 
the  traffic  management  function.  (Parti,  Chapter E,  Sec 
tionE.2,  page  1-87) 


MODELS  Requirement:  The  MODELS  concept  must  provide 
for  a  reasonable  interchange  of  information  and  data  between 
transportation  activities  and  both  nontransportation  and  non¬ 
logistics  activities.  (Part  I,  Chapter  E,  Section  E.2,  page  1-88) 

E.3  Movement. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  improving  existing  capabilities  for  recording  and  reporting 
of  transportation  movement  information  and  data.  (Parti, 
Chapter  E,  Section  E.3,  page  1-89) 


F.  REUTILIZATION  AND  MARKETING. 


F.5  Disposal  Automation. 

MODELS  Requirement:  The  MODELS  concept  must  recognize 
the  integral  role  of  DRMS  in  the  total  logistics  process  and 
should  interface  into  the  MODELS  conceptual  design  an  evolv¬ 
ing  DAISY  capability  for  on-line  visibility  of  excess  assets. 

Asset  visibility  should  be  available  to  wholesale  IMs  and  all 
retail-level  supply  echelons.  OSD  should  consider  the  integra¬ 
tion  of  DRMS  functional  procedures  into  the  DLSS  scope  of 
responsibility.  (Part  I,  Chapter  F,  Section  F.5,  page  1-94) 

In  summary,  these  functional  requirements  define  how  the  next  generation  of 
DLSS  should  be  organized  and  implemented.  Improved  logistics  management  and 
the  future  effectiveness  of  the  Military  Departments  are  greatly  dependent  on  the 
efficient  and  uniform  interchange  of  the  logistics  information  that  is  vital  to  the 
ability  of  U.S.  forces  to  accomplish  their  assigned  missions  anywhere  in  the  world  for 
as  long  as  it  takes  to  get  the  job  done. 

We  can  expect  to  have  the  right  materiel  where  it  is  needed,  when  it  is  needed 
only  if  we  take  the  comprehensive  view  of  the  complete  logistics  process  and  all  its 
complex  interrelationships  that  is  necessary  to  identify,  acquire,  supply,  transport, 
maintain,  and  reuse,  when  necessary,  military  end  items,  support  equipment,  and 
spare  parts.  While  the  system  has  worked  and  continues  to  work,  meeting  the 
requirements  stated  herein  should  enable  the  DoD  logistics  community  to  achieve 
significant  gains  in  productivity,  timeliness,  accuracy,  information  consistency,  and 
information  accessibility. 

The  next  part  of  this  report,  Part  II,  Operational  Requirements  and  Consider 
ations,  discusses  user  interface  and  automated  information  exchange  requirements 
and  methodologies. 


CHAPTER  A:  LOGISTICS  SYSTEMS  USER  REQUIREMENTS 


The  Department  of  Defense  (DoD)  logistics  community,  along  with  every  other 
functional  community  in  DoD,  is  in  the  midst  of  an  explosion  in  information  technol¬ 
ogy.  That  technological  explosion  requires  emphasis  on  information  management  as 
new  opportunities  and  capabilities  are  available  to  improve  decision-making  at 
every  management  level.  Today,  DoD  organizations  are  fielding  more  than  30 1 
major  logistics  information  processing  and  telecommunications  systems  designed  to 
assist  catalogers,  item  managers,  supply  officers,  transportation  officers,  combat 
commanders  and  their  staffs,  and  others  to  accomplish  their  jobs  more  effectively. 
Unless  those  systems  can  satisfy  the  intended  user’s  needs  by  providing  the  right 
information  at  the  right  time,  the  potential  for  improved  DoD-wide  logistics 
management  and  responsiveness  to  operational  requirements  will  not  be  fully 
realized. 

This  chapter  describes  the  functional  requirements  for  user  interfaces.  It 
specifically  discusses  information  exchange  requirements  that  address  inter-Service/ 
Agency  (S/A)  and  Service-to-Joint  Activities  requirements. 

A.l  Information  Exchange  Requirements. 

Logistics  operations  can  no  longer  be  performed  solely  on  an  intra-Service 
basis.  Even  the  Army,  with  its  Logistics  Intelligence  File  (LIP"),  must  rely  heavily 
upon  Defense  Logistics  Agency  (DLA)/Defense  Automatic  Addressing  System 
(DAAS)  telecommunication  capabilities  for  the  transmission  of  information,  upon 
inventory  control  point  (ICP)  and  depot  systems  for  information  on  supply 

lDoD  Appropriations  1986,  Hearings  before  the  Subcommittee  on  the  Department  of  Defense 
of  the  Committee  on  Appropriations,  House  of  Representatives,  99th  Congress.  Part  6  —  Automatic 
Data  Processing  Programs. 


availability,  release,  and  shipment,  and  upon  Military  Traffic  Management  Com¬ 
mand  (MTMC)/Military  Sealift  Command  (MSC)/Military  Airlift  Command  (MAC) 
systems  for  in-transit  shipping  status  information.  With  the  advent  of  weapons 
system-oriented  logistics  management,  secondary  asset  visibility  to  the  retail  level, 
and  increased  emphasis  on  standardization,  competition,  and  excess  item  reutili¬ 
zation,  the  need  for  up-to-date  exchange  of  information  between  S/As  becomes  a 
critical  requirement  that  must  be  satisfied  in  new  systems  and  procedures  now 
under  development. 

All  the  S/As  recognize  the  critical  need  for  improved  standardization  in  their 
own  internal  logistics  procedures  and  systems  interfaces.  Each  S/A’s  system 
development  effort  [i.e.,  the  Army’s  Commodity  Command  Standard  System  (CCSS); 
the  Navy’s  Stock  Point  ADP2  Replacement  (SPAR)  system;  the  Air  Force’s  Stock 
Control  and  Distribution  (SC&D)  system;  the  Marine  Corps’  Standard  Supply 
System  (M3S);  and  DLA’s  Standard  Automated  Materiel  Management  System 
(SAMMS)]  is  directed  at  incorporating  its  own  unique  data  element  dictionaries, 
thereby  establishing  a  set  of  logistics  data  elements  and  data  definitions  to  be 
utilized  throughout  its  specific  environment.  Similarly,  most  of  the  S/As  are 
implementing  high-speed  telecommunications  networking  capabilities  [Navy’s 
Stock  Point  Logistics  Integrated  Communications  Environment  (SPLICE);  Air 
Force’s  Logistics  Network  (LOGNET);  Marine  Corps’  Data  Network  (MCDN);  and 
Defense  Logistics  Agency  Telecommunications  Network  (DLANET)]  between  their 
own  Service’s  logistics  facilities  to  speed  the  communication  of  information 
electronically,  thereby  reducing  paper  flow  and  improving  supply  availability  and 
responsiveness.  (Note:  many  of  these  telecommunications  network  capabilities  are 
scheduled  to  be  integrated  into  the  Defense  Data  Network  (DDN)  in  the  next  5  to 
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10  years.)  However,  most  inter-S/A  transactions  now  require  DAAS  to  support  their 
communications,  and  the  only  common  inter-S/A  data  element  dictionary  for 
logistics  is  defined  by  the  Defense  Logistics  Standard  Systems  (DLSS)  procedures. 


One  objective  of  Phase  2  of  the  Modernization  of  DEfense  Logistics  Standard 
Systems  (MODELS)  project  is  to  identify  and  define  inter-S'A  system  interface 
requirements  to  better  satisfy  the  need  for  logistics  information  exchange  and 
improve  overall  operational  capability.  (See  Part  II,  Sections  B.4  and  B.5  for 
MODELS  Requirements  for  system  interoperability.) 

A. 2  Inter-S/A  Interface  Requirements. 

Many  of  the  inter-S/A  logistics  communication  requirements  originate  from 
the  Services  and  are  related  to  the  requirement  for  item  requisition  status  for  DLA, 
the  General  Services  Administration  (GSA),  or  Service  managed  and  maintained 
materiel.  That  requirement  is  primarily  satisfied  by  communications  from  origin  to 
destination  through  DAAS  using  the  Automatic  Digital  Network  (AUTODIN)  and 
standard  Military  Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP) 
follow-up  transactions.  DLA  Centers  do  provide  limited  on-line  inquiry  using 
terminal  connections  into  DLANET  and  offering  status  inquiry  capability  by 
National  Stock  Number  (NSN).  However,  for  a  period  of  time,  the  DLANET  became 
saturated  with  input  ports  (i.e.,  no  new  users  could  get  onto  the  network  until  DLA 
terminal  processors  were  enhanced  with  additional  processing  capability).  While 
that  situation  was  resolved  by  adding  processing  capability,  the  condition  will  occur 
again  as  demand  for  inquiry  access  continues  to  increase.  While  current  users  of  the 
DLANET  are  becoming  frustrated  with  the  quality  of  service  (response  time  and 
access  contention),  they  continue  to  request  on-line  capability  while  looking  for  more 
efficient  methods  of  logistics  information  access.  The  current  best  alternative  is  the 
MILSTRIP  follow-up  transaction,  but  the  most  frequently  used  alternative,  at  least 
for  Priority  Group  I  requisitions,  is  a  telephone  call  to  the  DLA  source-of-supply. 


In  interviews,  retail-level  equipment  maintenance  and  repair  personnel  indi 
cate  their  desire  for  on-line  requisition  processing  for  Priority  Group  I  materiel  and 
almost  immediate  confirmation  of  stock  availability  and  shipment  date.  That 
information  is  needed  for  repairing  weapons  systems  whose  repairs  are  delayed 
because  not  mission  capable  supply  (NMCS)  requisitioned  materiel  is  not  received. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
the  capability  to  implement  on-line  user  interfaces  with  ICPs 
for  stock  availability  and  requisition  status  inquiry  for,  as  a 
minimum,  Priority  Group  I  materiel  requirements. 

Another  area  of  DLA  operations  having  substantial  volumes  of  inter-S/A 
interface  is  the  Defense  Contract  Administration  Service  (DCAS).  DCAS  Adminis¬ 
trative  Contracting  Officers  (ACOs)  in  contractor  plants  and  DCAS  offices  in 
nine  regions  of  the  United  States  are  responsible  for  carrying  out  materiel  quality 
assurance  programs,  monitoring  production  schedules,  and  performing  data  and 
financial  management  activities.  Information  obtained  from  contractors  and  main¬ 
tained  by  the  ACOs  is  needed  by  DLA  and  Service  ICPs,  depots,  and  end-users.  That 
information  includes  production  quantities,  anticipated  shipment  and  shipment 
dates,  contract  requirements  and  special  provisions,  and  similar  data.  Any  changes 
in  production  or  shipment  information  may  be  of  vital  interest  to  the  entire  set  of 
DoD  potential  users  since  it  can  affect  reorder  quantities,  safety  stocks,  and 
maintenance  and  repair  decisions. 

These  contract  information  requirements  include  contracts  and  purchase 
orders  awarded  and  administered  by  other  S/A  acquisition  and  contract  administra 
tion  activities. 

MODELS  Requirement:  The  MODELS  concept  must  provide  a 
broad  base  of  DoD  users  with  access  (not  necessarily  in  real 
time)  to  data  from  contracting  and  contract  administration 
activities  that  maintain  information  related  to  contract 
content  and  status.  (Correlates  to  MODELS  Requirement  — 

Part  I,  Chapter  C,  Section  C.2.c,  page  1-38.) 


A.3  Interface  Requirements  of  the  Defense  Transportation  Function. 

The  Defense  transportation  function  is  the  composite  infrastructure  of  all  the 
DoD  organizations  responsible  for  the  movement  of  people,  their  personal  effects, 
and  most  military  materiel.  The  system  manages  the  movement  of  materiel  by 
truck,  rail,  ship,  barge,  and  air,  and  many  of  these  movements  are  performed  by 
commercial  carriers.  Those  carriers,  in  increasing  numbers,  are  developing  the 
capability  to  provide  near-real-time  shipment-in-transit-movement  visibility,  infor¬ 
mation  that  has  been  of  interest  to  both  shippers  and  receivers  for  many  years. 
However,  shipment  movement  information  and  specific-item  movement  status 
provide  distinctly  different  levels  of  information  availability.  While  a  Government 
Bill  of  Lading  (GBL)  or  shipping  manifest  will  contain  freight  descriptions  and  other 
transportation  information,  the  carrier  does  not  generally  know  the  contents  of  a 
package,  if  multiple  items  have  been  consolidated  (except  in  the  case  of  hazardous  or 
specially  controlled  items).  For  item-level  information  within  a  shipment  unit,  the 
inquiry  must  still  be  referred  to  the  originating  supply  or  transportation  shipping 
activity. 

The  first  step  in  providing  shipment  visibility  within  the  transportation  system 
should  be  electronic  information  interfaces  between  Defense  Transportation  System 
(DTS)  carriers  and  the  transportation  movement  managers.  That  information  is 
already  available  in  some  systems,  such  as  the  Air  Force’s  Aerial  Port  Documen¬ 
tation  and  Management  (ADAM  HI)  system  for  air  shipments.  The  second  step  is 
implementation  of  electronic  interfaces  between  commercial  carriers  and  traffic 
managers  for  Continental  United  States  (CONUS)  surface  shipping. 


MODELS  Requirement:  DLSS  procedures  must  provide  for 
meeting  the  growing  need  for  inter-S/A  standardization  of 
information  to  be  collected  and  electronically  communicated 
between  DoD  transportation  agencies  and  customers  and, 
between  DoD  and  commercial  transportation  activities. 

(Correlates  to  MODELS  Requirement  —  Part  I,  Chapter  E, 

Section  E.3,  page  1-89.) 

A.4  Service-to-Service  Interface  Requirements. 

Currently,  a  good  example  of  a  major  Service-to-Service  interface  requirement 
is  the  requisitioning,  shipment,  and  receipt  of  ammunition.  The  Army,  as  the  Single 
Manager  for  Conventional  Ammunition,  provides  conventional  ammunition  logis¬ 
tics  support,  and  therefore  logistics  information,  to  the  entire  DoD.  While  ammu¬ 
nition  is  unlike  any  other  commodity  in  that  it  is  a  high-dollar  commodity  charac¬ 
terized  by  high  volume  and  tonnages  involving  many  different  types  of  ammunition 
that  require  special  handling  and  storage  and  detailed  tracing  and  accountability 
records,  the  systems  used  to  manage  the  process  may  have  a  broader  applicability  in 
design  if  not  in  exact  implementation. 

In  compliance  with  Department  of  Defense  Directive  (DoDD)  5160.65,  which 
requires  the  Army  to  develop,  design,  and  centrally  maintain  a  DoD- wide  automated 
data  system  covering  the  logistics  functions  in  their  Single  Manager  for  Conven 
tional  Ammunition  assignment,  the  Army  is  implementing  a  Defense  Standard 
Ammunition  Computer  System.  The  system,  which  is  envisioned  as  a  centrally- 
located  pair  of  processors  at  Rock  Island,  Illinois,  will  consist  of  two  data  bases  of 
ammunition  relevant  information  networked  to  other  Service  systems  supporting 
ammunition- related  logistics  functions.  The  system  will  then  standardize  and 
control  all  conventional  ammunition  acquisition,  logistics,  and  financial  processes. 
The  completed  system  is  scheduled  to  be  deployed  during  Fiscal  Years  1989  and  1990 
and  will  provide  other  Service  ammunition  managers  on-line  access  to  a  full  range  of 
logistics  information  required  for  decision-making.  This  Service-to-Service  interface 


requirement  is  already  extending  beyond  ammunition,  as  additional  weapons 
systems  (e.g.,  Air  Force  and  Navy  F-4  aircraft)  and  weapons  system  spare  parts  are 
used  by  multiple  Services. 

MODELS  Requirement:  Modernized  DLSS  procedures  and  the 
MODELS  information  exchange  technology  concepts  must 
provide  standardized  interfaces  to  unique  commodity  systems 
(e.g.,  ammunition,  petroleum).  Eventually  such  unique 
Service-to-Service  and  Service-to-DLA  procedures  and  auto¬ 
mated  systems  must  be  fully  integrated  into  the  MODELS 
concept. 


Since  the  reorganization  of  the  nation’s  military  establishment  into  the  DoD 
after  World  War  II,  the  roles  of  the  Office  of  the  Secretary  of  Defense  (OSD),  JCS, 
Commanders-in-Chief  (CINCs),  Defense  and  Joint  Agencies,  and  the  Military 
Departments  have  evolved  as  each  element  of  the  DoD  has  striven  to  improve  its 
capability  to  participate  in  defending  the  nation  and  to  support  its  Fighting  forces  in 
a  deployed  military  action  (as  this  is  being  written,  reorganization  of  the  JCS  to 
strengthen  its  role  is  being  considered).  Of  primary  concern  to  all  is  accomplishing 
this  mission  within  the  constraints  of  budgetary  limitations. 

The  evolutionary  development  of  DoD  has  taken  two  paths.  On  the  one  hand, 
OSD  has  tried  to  increase  logistics  support  efficiency  and  reduce  costs.  On  the  other 
hand,  the  JCS,  CINCs,  and  Joint  Agencies  have  concentrated  on  planning  for  war 
and  its  contingencies  and  on  force  readiness.  The  Services  have  participated  in  both 
evolutionary  processes,  their  contributions  being  limited  to  some  degree  by  their 
traditional  ways  of  doing  business.  This  somewhat  uneasy  dichotomy  between  the 
responsibility  for  the  preparation  of  combat  forces  and  the  responsibility  for  prepar¬ 
ing  the  plans  to  Fight  the  war  contributes  to  the  lack  of  coordination  between  the  two 
arenas. 
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Traditionally  systems  development  in  the  Joint-Agency  arena  has  been  in  the 
planning  area.  However,  over  the  past  few  years  (since  the  NIFTY  NUGGET  — 78 
exercise)  increasing  emphasis  has  been  placed  on  developing  decision  support 
systems  for  executing  war  plans.  One  of  the  actions  taken  was  establishment  of  the 
Joint  Deployment  Agency  (JDA).  Its  mission  is  to  "act  as  the  focal  point  for  deploy¬ 
ment  associated  decision-making  information”  and  to  "adjust  movement  plans, 
schedules,  and  modes  of  transportation  and  direct  implementation  of  deployment 
decisions.”  That  includes  monitoring  of  resupply  cargo  to  facilitate  lift  allocation 
decisions  and  facilitating  prioritization  of  critical  resupply  movements. 

The  Joint  Deployment  System  (JDS)  is  a  component  of  the  evolving  Joint 
Operations,  Planning,  and  Execution  System  (JOPES),  being  developed  by  JCS. 
That  system  is  vitally  interested  in  the  initial  movement  of  units  and  equipment/ 
material  and  their  subsequent  sustainment  (i.e.,  the  logistics  process).  Therefore, 
the  JDA  components  responsible  for  JDS  are  very  interested  in  monitoring  the 
development  and  implementation  strategies  of  the  MODELS  concept.  Moderni¬ 
zation  of  the  DLSS  could  be  a  key  factor  in  the  development  of  both  deployment  and 
sustainment  capabilities  in  JDS. 

In  addressing  sustainment,  the  primary  objectives  of  JOPES  are  to  compare 
wartime  requirements  to  available  assets  to  determine  feasibility  and  to  allocate 
assets  among  competing  requirements  on  a  global  basis.  To  meet  these  objectives, 
MODELS  must  provide  JCS/CINC  visibility  of  system  inventories  and  must  accept 
and  implement  JCS  allocation  guidance  to  ration  available  stocks  among  competing 
claimants. 

One  problem  being  addressed  in  JOPES/JDS  is  that  of  allocation  and  reallo¬ 
cation  of  critical  supply  and  transportation  assets  during  a  crisis  or  in  wartime.  The 
problem  exists  because  there  is  no  common  basis  for  communication  between 


planning  personnel  and  operations  personnel  to  express  planned  supply  require¬ 
ments  in  terms  that  can  be  executed.  Military  plans  define  supply  requirements  in 
terms  of  10  classes  and  several  subdivisions  of  these  classes.  In  the  operational 
world,  supplies  are  identified  in  78  groups,  619  classes,  and  several  million  NSNs. 
The  problem  is  further  compounded  by  the  differences  between  supply  and 
transportation  requirements,  with  supply  centering  on  and  using  requisition 
number  and  NSN  and  transportation  centering  on  and  using  the  Transportation 
Control  Number  (TCN).  The  recently  approved  use  of  the  Federal  Supply  Class 
(FSC)  to  be  transmitted  in  the  Advance  Transportation  Control  and  Movement  Data 
(ATCMD)  for  MAC  shipments  addresses  part  of  the  problem  of  requisition  tracking 
between  supply  and  transportation.  The  DLSS  could  make  further  major 
contributions  to  the  overall  supply-transportation-JOPES  integration  effort  by 
providing  a  structure  for  better  resolution  of  this  supply-transportation  problem.  At 
present,  procedures  developed  by  the  Joint  Agencies  have  not  evolved  to  the  extent 
that  specific  functional  requirements  can  be  identified  in  detail  for  MODELS.  The 
evolving  JOPES  (including  the  JDS),  along  with  S/A  system  modernization  projects 
[many  of  which  are  indirectly  providing  information  to  the  Worldwide  Military 
Command  and  Control  System  (WWMCCS)  Information  System  program],  and 
MODELS  appear  to  be  logical  approaches  to  integrating  logistics  planning  and 
execution  solutions. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
lor"  a  working  interface  between  joint  operations  systems  and 
the  DLSS.  (Correlates  to  MODELS  Requirement  —  Part  I, 

Chapter  E,  page  1-81.) 


CHAPTER  B:  METHODS  OF  LOGISTICS  INFORMATION  EXCHANGE 


Rapidly  developing  technologies  in  data  processing,  telecommunications,  infor¬ 
mation  management,  and  related  information  processing/dissemination  fields  have 
created  a  broad-based  demand  for  change  to  incorporate  these  new  capabilities  into 
all  aspects  of  defense  operations,  including  logistics  management.  These  new 
capabilities  in  turn  offer  opportunities  to  achieve  significant  advances  in  providing 
users  with  the  information  needed,  in  the  report  format  needed,  and  at  the  time 
needed  to  make  better  management  decisions. 

The  following  pages  discuss  emerging  technologies  that  should  be  incorporated 
into  the  MODELS  system  concept  to  effectively  meet  today’s  and  tomorrow’s  logistics 
management  requirements. 

B.l  Data  Standardization. 

Data  and  information  are  not  synonymous.  Information  is  assembled  from 
data  in  the  same  way  products  are  assembled  from  inventory.  Because  organizations 
rarely  agree  on  the  data  they  will  use  to  build  their  information,  many  different 
combinations  and  permutations  of  data  are  used  to  create  the  desired  information. 

Data  is  facts  plus  meanings.  Without  meanings,  facts  are  just  jumbles  and 
strings  of  symbols.  To  establish  control  over  data  meanings,  a  data  resource  man¬ 
ager  must  establish  a  set  of  data  standards,  and  those  standards  must  be  based  on  an 
organization-wide  consensus  of  the  meanings  of  all  terms  that  define  facts.  Data 
standards  control  what  data  will  be  put  on  the  organization’s  computers  and  used  by 
employees  to  create  the  information  required  to  run  the  organization’s  operations. 

Data  standards  are  data  elements  and  their  associated  meanings  established 
by  management  to  control  the  use  and  application  of  the  specified  data  elements. 
The  DoD  Logistics  Data  Element  Standardization  and  Management  Program 


(LOGDESMAP)  is  chartered  to  provide  a  common  base  of  standard  logistics  data 
elements  and  related  features  for  use  throughout  DoD  logistics  systems.  This 
common  base  will  eliminate  duplication  in  logistics  data  systems  and  will  facilitate 
the  interchange  of  data  between  and  among  such  systems.  Thus,  it  is  an  important 
component  and  building  block  in  the  MODELS  implementation. 

MODELS  Requirement:  The  expanded-DLSS  procedures  must 
provide  for  the  identification,  definition,  control,  and  dissemi¬ 
nation  of  data  standards.  This  role  should  include  the  develop¬ 
ment  of  data  dictionaries.  (Correlates  to  MODELS  Require 
ment  —  Part  I,  Chapter  A,  Section  A.l,  page  1-9.) 


B.2  Variable-Length/Variable-Field  Transaction  Records. 

A  major  information  processing  and  communication  restriction  continually 
cited  at  Congressional  hearings  and  Major  Automated  Information  System  Review 
Council  (MAISRC)  reviews,  in  system  modernization  plans,  and  in  conversations 
concerning  obsolete  data  techniques  is  the  use  of  the  "80-column  card  format”  for 
logistics  system  transactions.  This  technique  is  obsolete  and  inhibits  comprehen 
sive,  effective  information  communication.  Since  all  of  the  Services  and  DLA  are  in 
the  process  of  modernizing  their  logistics  applications,  incorporating  data  base 
management  system  (DBMS)  technology,  implementing  Local  Area  Networks 
(LANs)  and  wide  area  networks,  and  establishing  Defense  Communications  Agency 
(DCA)-connecting  nodes  to  the  DDN,  this  is  the  time  to  begin  implementation  of 
variable- length  and  variable-field  transaction  records  for  inter-S/A  communication 
of  logistics  information.  In  fact,  that  implementation  should  have  already  started. 

Names  of  parts  and  vendor  part  numbers,  organization  ship  to  and  bill  to 
!  names  and  addresses,  order  quantities,  special  instructions,  contractual  information, 

j  transportation  information  (particularly  for  personal  effects),  and  similar  logistics 

information  vary  greatly  in  length.  To  accommodate  the  maximum  required  length 
without  truncation  or  to  transmit  only  the  information  needed  without  sending 
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blank  space  is  infeasible  using  a  fixed-length  record.  Therefore,  the  computer  and 
telecommunications  industries  have  developed  and  implemented  the  variable-length 
record. 

Most  character  code  sets  provide  a  control  character  that  is  appropriate  to 
terminate  a  character  string  or  data  segment.  The  American  National  Standards 
Institute  (ANSI),  specifically  the  ANSI  X12  Electronic  Business  Data  Interchange 
(EBDI)  Standards  Committee,  has  established  the  V  as  a  data  element  separator  and 
the  'N/L’  indicator  as  the  end  of  a  data  segment. 

Today’s  information  management  environment  is  capable  of  processing 
variable-field  lengths  and  variable-field  records.  Variable-field  lengths  allow  a  user 
to  limit  the  message  to  the  amount  of  information  necessary  for  the  particular 
situation  [i.e.,  the  Department  of  Defense  Activity  Address  Directory  (DoDAAD)- 
coded  address  of  where  materiel  is  to  be  shipped],  and  to  transmit  all  the  data 
necessary  in  an  unusual  situation  (i.e.,  a  complete  station  name,  if  necessary  for  a 
special  deployment  condition). 

The  variable-field  record  is  a  transaction  construct  designed  to  permit  trans¬ 
mission  of  the  data  necessary  to  fully  identify  the  type  of  record  and  the  action  to  be 
taken.  For  example,  a  requisition  follow-up  status  request  record  might  contain  only 
the  record  type  identifier  (e.g.,  requisition  follow-up),  the  requisition  number,  the 
source  of  supply,  and  a  question  mark  (?)  to  tell  the  receiving  ICP  system,  "Send  me 
all  the  information  on  this  requisition.”  Both  user  time  in  completing  the 
transaction  and  communication  system  costs  are  saved  by  the  variable-length 
record.  A  partial,  sample  transaction  record,  also  known  as  a  data  segment,  is  shown 
and  described  in  Figure  B-l. 


FIGURE  B-1.  TRANSACTION  RECORD/DATA  SEGMENT  DIAGRAM 


The  following  diagram  illustrates  how  a  transaction  record  (data  segment)  is  diagrammed 
and  provides  references  to  codes  and  data  elements  used  in  the  EBDI  Standard  Note  that  the 
actual  interchange  of  information  does  not  include  all  the  reference  characters  shown  in  the 
diagram.  Only  the  Data  Segment  Identifier  characters,  the  values  for  each  Data  Element,  the 
Data  Element  Separator,  and  the  Data  Segment  Terminator  characters  are  actually  transmitted. 
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(1)  Data  Segment  Identifier  -  The  two  or  three  characters  assigned  to  identify  the  segment 
(Document  Identifier  Code). 

(2)  Data  Element  Reference  Designator  -  The  data  segment  identifier  plus  a  two-digit 
sequence  number. 

(3)  Data  Dictionary  Reference  Number  -  The  index  reference  number  to  the  Data  Dictionary 
Standard  where  the  content  of  all  data  elements  is  defined. 

(4)  Data  Element  Separator  -  The  character  selected  by  sender  which  precedes  every  data 
element,  whether  the  data  element  is  used  or  not. 

(5)  Data  Element  Title  -  Name  of  the  data  element. 

(6)  Data  Segment  Terminator  -  The  character  selected  to  end  each  data  segment 

(7)  Data  Element  Requirement  Designator  -  Indicates  when  this  element  must  be  included  in 
an  electronic  document. 

M  =  Mandatory  :  C  =  Conditional  :  O  =  Optional 

(8)  Data  Element  Type  -  Specifies  the  characters  that  may  be  used 

N  =  Numeric  :  D  =  Decimal  :  AN  =  Alphanumeric  :  S  =  String 

ID  =  Identifier,  a  specific  code  taken  from  a  table  defined  in  the  Data  Dictionary 
Standard,  such  as  a  unit  of  measure 

(9)  Data  Element  Length  -  The  minimum  and  maximum  length  of  the  data  element  in 
characters. 

(10)  Data  Element  Relational  -  Defines  relationship  between  two  or  more  data  elements  in  a 

group. 
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A  variation  of  this  approach  is  used  by  the  Defense  Logistics  Services  Center 
(DLSC)  for  updating  selected  data  elements  in  the  Defense  Integrated  Data  System 
(DIDS)  data  base.  A  four-digit  data  element  identifier  code  (as  specified  in  the  DIDS 
data  element  dictionary)  is  included  in  the  record  followed  by  a  space  and  the  value 
of  the  data  element.  A  pound  sign  (#)  is  used  to  separate  each  identifier  code/data 
value  combination.  Approximately  85  percent  of  the  updates  submitted  in  this 
manner  are  for  changes.  Forty-five  data  elements  can  be  added  through  this 
transaction  type,  65  data  elements  are  subject  to  change,  and  39  data  elements  can 
be  deleted.  Updates  in  this  format  can  be  submitted  on  80-column  cards  or  in 
variable-length  formats.  These  transactions  are  in  addition  to  and  separate  from 
existing  fixed-format  records. 

Thus,  the  following  two  variable-length  records  have  to  be  considered  for 
implementing  modernized  DLSS  transaction  formats: 

•  A  variable-length  record  in  which  the  fields  within  the  transaction  record 
are  predefined  and  if  not  needed,  are  omitted  by  use  of  a  double  asterisk  (**) 
set  of  field  delimiters,  indicating  no  data  for  the  designated  field. 

•  A  variable-length  record  in  which  only  a  document  identifier.  Field  identi¬ 
fier  code(s),  and  associated  field  value(s)  are  included  in  the  transaction 
record. 

Both  of  these  transactions  have  advantages  and  disadvantages  associated  with 
their  formats.  The  first  format  is  better  when  transmitting  initial  sets  of  data  such 
as,  for  example,  an  initial  requisition.  The  second  format  is  better  when  making 
changes  to  a  transaction  already  recorded  such  as,  for  example,  a  requisition 
modifier  document.  Both  alternatives  will  be  evaluated  during  MODELS,  Phase  3. 

B.2.a  The  Variable-Length/Variable-Field  Transaction  and  ANSI  X12  EBDI 

Standards. 

The  variable-length/variable-field  transaction  record  is  gaining  wide  accep¬ 
tance  in  the  commercial  world  for  logistics  information  traffic  and  other  electronic 


11-15 


communications.  ANSI,  the  recognized  coordinator  and  clearinghouse  for  informa¬ 
tion  on  national  and  international  standards,  has  chartered  the  X12  committee  to 
develop  uniform  methods  for  interindustry  electronic  interchange  of  business 
transactions. 

The  ANSI  X12  EBDI  Standards  consist  of  transaction  set  standards,  a  data 
dictionary,  and  transmission  control  standards.  Transaction  set  standards  define  the 
procedural  format  and  data  content  requirements  for  business  transactions,  such  as 
purchase  orders.  The  data  dictionary  defines  the  precise  content  and  meaning  for 
data  elements  used  in  building  transaction  sets.  Transmission  control  standards 
define  the  formats  for  the  information  required  to  interchange  data.  These  controls 
are  already  in  use  by  some  industries,  including  the  grocery  industry,  representing 
manufacturers,  distributors,  and  brokers. 

Specific  EBDI  transactions  already  developed  or  actively  under  development 
are  shown  in  Table  B- 1.  Additional  transaction  standards  are  being  formulated  and 


TABLE  B-1.  DRAFT  PROPOSED  ELECTRONIC  BUSINESS  DATA  INTERCHANGE  TRANSACTION 

STANDARDS 


Purchase  Order' 

Shipping  Notice2 

Price/Sales  Catalog ' 

Purchase  Order  Acknowledgment' 

Receiving  Advice' 

Request  for  Quotation ' 

Purchase  Order  Change  Request' 

Invoice' 

Reply  to  Request  for  Quotation 

Supplier  Initiated  Purchase  Order  Change 
Request3 

Remittance/Payment  Advice2 

Product  Transfer  and  Resale  Report3 

Purchase  Order  Change  Acknowledgment' 
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Order  Status  Inquiry3 
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Planning  Schedule' 

Order  Status  Report3 

Waiver  Request4 

Price  Authorization  Acknowledgment/ 

Status3 

Quality  Information4 

1  Proposed  standard  submitted  to  ANSI  Board  for  approval 

2  Proposed  standard  submitted  for  concurrent  and  public  review 
J  Transactions  sets  under  development 

4  T ransaction  set  areas  approved  for  consideration 


sent  to  the  respective  industries  for  review  and  approval.  Recently,  in  support  of  the 
DoD  EBDI  test  for  transmission  of  the  GBL,  an  X12  subcommittee  drafted  a  GBL 
transaction  standard. 

Commercial  industries  supporting  and  endorsing  the  EBDI  ANSI  X12  Stan 
dards  include  retail,  manufacturing,  electrical,  chemical,  automotive,  aluminum, 
communications,  computer,  banking/corporate/finance,  and  office  products.  In  addi 
tion  to  the  ANSI  X12  EBDI  Standards  that  cover  general  business  transactions, 
other  ANSI  X12  EBDI  Standards  include: 

•  Uniform  Communications  Standard  (UCS),  primarily  used  in  the  retail  food 
business 

•  Warehouse  Information  Network  Standards  (WINS),  which  facilitate 
communications  in  the  warehouse  industry 

•  Automated  Carrier  Interface  (designed  for  ocean  carriers),  Rail  Waybill 
Interchange  (RWI),  and  Motor  Carrier  Waybill  Interchange  (MCWI)  used 
by  transportation  carriers. 

As  with  several  other  technologies  discussed  in  this  report,  the  implementation 
of  the  standards,  becoming  commonly  known  as  EBDI,  is  still  very  much  in  its 
infancy.  However,  as  demonstrated  by  the  number  of  different  industry  sectors 
supporting  the  concept  and  a  recent  EBDI  Conference  in  Washington,  D.C.  attended 
by  more  than  2,500  representatives  from  the  above  industry  sectors,  other  indus 
tries,  and  government,  the  concept  is  being  widely  accepted.  Thus,  in  a  matter  of 
time,  transacting  business  electronically  will  probably  become  a  generally  accepted 
method. 

The  DoD  processes  millions  of  business  transactions  annually  with  commercial 
firms.  Some  of  those  firms  (e.g.,  General  Motors  and  Johnson  &  Johnson)  are 
already  requiring  their  suppliers  to  implement  an  EBDI  capability  conforming  to  the 
ANSI  X12  EBDI  Standards.  If  DoD  wishes  to  continue  to  foster  competition  in 
procurement  and  reduce  its  costs  of  doing  business  with  its  vendors,  it  may  need  to 


endorse,  participate  in,  and  implement  ANSI  X12  EBDI  Standards  being  developed 
for  private-sector  logistics  functions.  Upon  such  an  endorsement,  the  DoD  logistics 
community  must  also  accept  and  endorse  the  variable-length/variable-field  records 
established  by  the  X12  committee  standards.  Acceptance  of  these  standards  implies 
that  a  close  working  relationship  will  be  developed  with  subcommittees  developing 
standards  so  that  the  DoD-specific  requirements  for  conducting  business  can  be 
incorporated  into  both  existing  and  developing  EBDI  standard  transaction  formats. 
It  also  requires  acceptance  of  the  ANSI  X12  global  data  dictionary. 

Such  a  DoD  acceptance  would  have  a  significant  impact  on  DLSS-defined 
transactions.  Every  transaction  format  and  every  Logistics  Data  Resource  Manage¬ 
ment  System  (LOGDRMS)-defined  data  element  would  have  to  be  reviewed  and 
revised  as  necessary  to  conform  to  jointly-developed  ANSI  X12  EBDI  Standards. 
Those  reviews  and  revisions  will  not  be  quick,  easy,  or  inexpensive.  However,  the 
task,  if  considered  from  the  perspective  that  it  is  merely  one  component  of  the 
modernization  of  the  DLSS  along  functional  lines  (as  discussed  in  Part  I  of  this 
report),  and  a  necessary  step  in  the  conversion  to  variable- length  record  formats  (as 
discussed  above),  can  certainly  be  done  over  the  period  of  several  years  during  the 
DLSS  modernization  process.  The  MODELS  design  concept  must  facilitate  change 
and  provide  flexibility.  As  such,  it  must  integrate  into  the  operational  systems  the 
new,  standard  transactions  as  they  are  defined  and  published  in  modernized  DLSS 
procedures. 


MODELS  Requirement:  DLSS  transaction  formats  should  be 
variable-length  records  and  should  conform  to  an  electronic 
data  exchange  standard.  Serious  consideration  should  be 
given  to  using  ANSI  X12  EBDI  Standards  to  establish 
compatibility  with  the  commercial  sector.  Therefore,  DLSS 
transaction  formats  should  be  formulated  and  established  in 
cooperation  with  the  Transportation  Data  Coordination  Com¬ 
mittee,  the  ANSI  X12  Committee  and  its  associated  subcom¬ 
mittees,  and  industry  representatives. 


The  variable-length/variable-field  transaction  record  provides  the  opportunity 
to  take  full  advantage  of  modern  processing  and  telecommunications  technologies 
and  to  transmit  both  common  and  S/A-unique  data  within  a  single  transaction. 

These  changes,  while  they  will  take  several  years  to  implement,  provide  the 
flexibility  to  (1)  accommodate  all  intra-S/A  and  inter-S/A  data  communication  needs 
for  the  future,  (2)  enable  rapid  changes  in  data  transmission  requirements  to  meet 
management’s  dynamic  information  needs,  (3)  incorporate  and  take  full  advantage 
of  new  processing  and  communications  technologies  as  they  become  generally 
available  [gateways,  Integrated  Services  Data  Networks  (ISDNs),  distributed  data 
base  management  systems  (DDBMSs)],  (4)  satisfy  most  of  the  processing  and 
telecommunications  requirements  stated  above  for  an  eventual  DoD-wide  logistics 
community  information  network,  and  (5)  accommodate  DoD-to-commercial  inter¬ 
faces. 

B.3  Interactive  Data  Access  and  Update. 

Three  modes  of  automated  information  access  exist  in  today’s  processing 
environment: 

•  Interactive,  on-line  inquiry 

•  Electronic  mail 

•  Batch  processing. 


Each  of  these  access  methods  is  available  and  used  in  DoD  and  many  commer¬ 
cial  systems  today.  They  will  all  remain  acceptable  methods  of  information  access 


for  the  foreseeable  future.  However,  the  circumstances  under  which  each  method  is 
most  advantageous  are  changing  and  will  continue  to  do  so. 

B.3.a  On-line,  Interactive  Access. 

Integrating  user  input  and  machine  output  in  a  dynamic,  real-time,  give-and- 
take  process  is  considered  the  optimum  mode  of  computer  access  by  the  computer 
literate  end-user.  Users  interviewed  at  retail-level  supply  centers  and  maintenance 
personnel  who  have  used  personal  computers  indicated  a  desire  for  interactive 
inquiry  into  available  retail  and  wholesale  stocks,  interactive  inquiry  for  requisition 
status,  and,  if  possible,  interactive  requisitioning  to  ensure  that  available  stocks 
would  be  issued  to  fulfill  their  request.  While  this  capability  would  be  desirable  for 
all  priorities  of  requisitions,  interviewees  all  acknowledged  that  only  Priority 
Group  I  requisitioning  access  would  be  practical. 3 

A  major  issue  to  be  resolved  relative  to  on-line,  interactive  supply  availability 
inquiry  is  that  interactive  inquiry  for  stock  availability  only  provides  the  user  with 
information  that  the  stock  "may”  be  available  when  the  subsequent  requisition  is 
processed;  it  does  not  guarantee  availability.  Therefore,  decisions  might  be  made  on 
the  basis  that  stock  would  arrive  within  a  particular  time  frame  when,  in  fact,  by  the 
time  the  actual  requisition  is  processed,  the  stock  might  be  depleted  and  the  item 
would  have  to  be  backordered.  Some  on-line,  interactive  stock  availability  inquiry  is 
currently  being  performed  successfully,  and  users  with  that  capability  are  satisfied 
with  the  processing.  However,  if  that  capability  is  provided  to  the  entire  logistics 

3An  interesting  observation  from  these  field-level  users  is  that  any  interactive  inquiry  and 
update  requisitioning  capabilities  should  permit  only  a  single  inquiry  per  item,  and  the  system 
response  should  be  an  acknowledgment  that  the  requested  quantity  or  a  lesser  quantity  was 
available  for  issue.  The  reasons  for  these  restrictions  are  to  keep  end  users  from  identifying  the 
total  quantity  available  and  therefore  ordering  more  than  needed  if  they  perceive  a  short  supply 
condition.  For  example,  if  a  user  needs  three  items,  and  could  determine  that  only  four  were 
available,  he/she  might  be  tempted  to  order  all  four  under  the  assumption  that  the  next  time  he/she 
needed  the  item,  none  would  be  available 


community,  even  for  Priority  Group  I  inquiries  only,  that  satisfaction  could  change 
dramatically. 

Thus,  while  there  is  a  real  need  for  some  level  of  immediate  access  to  informa¬ 
tion  on  stock  availability,  particularly  to  meet  Priority  Group  I  requirements,  the 
optimum  solution  to  satisfying  the  requirement  is  not  immediately  obvious  and 
additional  analysis  must  be  performed. 

While  interactive  stock  availability  inquiries  require  the  resolution  of  many 
issues,  such  is  not  the  case  with  interactive  requisition  status  inquiries.  In  this 
situation,  the  end-user  requires  only  the  most  currently  reported  status  of  a 
requisition  that  has  already  been  initially  processed.  Such  a  system  must  have  the 
capability  to  provide  the  requested  information  within  a  few  seconds  of  inquiry,  and 
the  requisitioner  should  not  be  required  to  identify  the  system  from  which  informa¬ 
tion  must  be  retrieved.  That  is,  the  requester’s  computer  system  network  must  have 
a  network-switching  capability  that  automatically  connects  the  user  to  the  system 
containing  the  requested  information.  This  distributed  data  management  capability 
is  discussed  in  Part  II,  Chapter  B,  Section  B.6. 

As  S/As  implement  modernization  programs,  incorporating  DBMS  technology 
and  the  ability  to  provide  interactive,  on-line  information  access,  demands  for  such 
access  internal  to  the  S/A  will  increase.  The  demand  will  not  be  long  denied  once  the 
capability  is  available  because  arguments  for  substantial  increases  in  productivity 
and  associated  cost  avoidances  will  dominate  decisions.  Once  intra-S/A  interactive 
access  is  established,  the  next  demand  will  be  for  inter-S/A  interactive  access  to 
satisfy  a  broad  range  of  operational  and  management  decision-making  require¬ 
ments.  Therefore,  the  Defense  Logistics  Standard  Systems  Office  (DLSSO)  must 
identify  the  standards  for  how,  who,  what,  when,  and  how  much  inter-S/A  inter 
active  systems  inquiry  and  update  capability  can  and  will  be  provided  in  peacetime 


and  wartime.  These  standards  must  be  established  now  to  serve  the  DoD  logistics 
community  of  tomorrow. 

MODELS  Requirement:  The  modernized  DLSS  must  estab¬ 
lish  procedures  and  standards  for  DoD-wide  interactive  logis¬ 
tics  information  inquiry. 

B.3.b  Electronic  Mail  Access. 

On-line  access  through  an  electronic  network  to  leave  transactions/messages 
for  electronic  processing  and/or  human  on-line  retrieval  is  rapidly  becoming  a 
convenient  method  for  person-to-person  communication  of  descriptive  text,  graphics, 
and  alphanumeric  information  not  amenable  to  standard  transaction  formatting. 
The  method  is  particularly  appropriate  when  a  single  set  of  information  (e.g.,  pipe¬ 
line  performance  reports)  must  be  distributed  quickly  to  a  geographically  broad- 
based  group  of  users.  In  the  electronic  network,  a  mailing  list  can  be  predefined  and 
the  set  of  information  can  be  electronically  transmitted  almost  instantaneously  to  all 
recipients. 

Within  the  logistics  community,  electronic  mail  could  also  be  a  useful  method 
for  rapid  information  inquiry  avoiding  problems  of  system  degradation  from  heavy 
loads  of  interactive  inquiry  processing  and  the  need  to  implement  extensive  security 
measures  to  validate  and  restrict  different  levels  of  individual  access  to  records  or 
data  elements.  For  example,  an  Inventory  Manager  (IM)  could  leave  an  electronic 
mail  message  in  a  designated  system  mailbox  of  a  retail-level  supply  activity, 
requesting  information  concerning  the  availability  of  several  critically  needed  parts 
not  currently  in  stock  at  any  depot.  The  retail-level  supply  personnel  could  be 
quickly  notified  of  the  electronic  request,  could  check  system  inventory  records  and 
review  the  request  with  maintenance  and  repair  managers,  and  then  either  send  a 
message  back  to  the  originator’s  system  or  leave  the  response  message  in  the 
original  mailbox  for  the  originator  to  check.  This  electronic  mail  processing  reduces 
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transactional  message  traffic,  improves  information  flow  between  the  parties,  avoids 
costly  and  time-consuming  telephone  call-back  exchanges,  and  reduces  require 
ments  for  providing  security  access  to  the  computer  for  every  possible  organization 
that  might  request  information. 

Electronic  mail  inquiry  is  the  current  method  used  in  the  Army  LIF  system  for 
information  on  the  status  of  requisitions.  The  information  inquiry  is  entered  in  a 
predefined  format  so  that  it  can  be  automatically  processed.  Research  is  also  being 
conducted  by  the  Navy  to  employ  computational  linguistics  and  artificial  intelli 
gence  data- processing  techniques4  to  develop  capabilities  that  will  enable  systems  to 
automatically  handle  a  variety  of  messages,  from  highly  formatted  messages  with 
little  English  description  to  messages  consisting  entirely  of  English  narrative. 

Electronic  mail  would  be  a  valuable  communications  method  for  logistics  infor 
mation  during  a  mobilization  or  deployment  period.  Events  during  such  a  period 
will  create  substantial  data-processing  surges,  restricting  interactive  inquiry  and 
processing.  Units  on  the  move  to  new  locations  could  use  electronic  mail  capability 
to  submit  logistics  transactions  (e.g.,  requisitions),  with  subsequent  transmission  of 
responses  to  the  originator’s  mailbox.  Then,  when  time  and  conditions  permit,  the 
deployed  unit  could  retrieve  the  status  responses. 

Electronic  mail  will  increase  as  a  means  for  making  logistics  information 
available  on  a  more  timely  basis.  Therefore,  the  DLSS  need  to  standardize  proce 
dures  for  using  electronic  mail  for  inter-S/A  logistics  communications. 


4 Computational  Linguistics  —  the  use  of  computer  capability  for  narrative  message 
interpretation  that  consists  of  ( 1)  message  decomposition,  which  determines  the  overall  structure  of 
a  message,  and  (2)  narrative  analysis,  which  generates  the  structure  that  enables  the  computer  to 
interpret  the  English  narrative. 

Artificial  Intelligence  —  the  development  of  a  machine  capability  to  perform  functions 
normally  concerned  with  human  intelligence,  such  as  learning,  adapting,  reasoning,  self-correction, 
and  automatic  improvement. 
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MODELS  Requirement :  The  MODELS  concept  must  provide 
for  an  electronic  mail  capability. 

B.3.c  Batch  Processing. 

Using  standardized  transaction  formats  with  a  coded-source  address  trans 
mitted  through  the  AUTODIN  system  is  the  most  dominant  method  of  remote 
system  access  in  use  in  the  DoD  logistics  community.  It  is  used  for  data  input, 
information  inquiry,  and  status  reporting.  In  the  future,  batch  processing  will  still 
be  a  valid  method  for  accessing  logistics  information.  Replenishment  requisitions, 
Materiel  Release  Orders  (MROs)  and  Materiel  Release  Confirmations  (MRCs), 
routine  performance  measurement  data,  routine  contracts  data,  invoice  data,  and 
similar  routine  logistics  information  do  not  require  the  added  costs  of  near-real-time 
or  interactive  processing.  The  information  can  be  accumulated  into  output  files  and 
transmitted  in  batches  to  be  processed  at  the  appropriate  receipt  facilities,  on  a 
scheduled,  periodic  basis. 

The  logistics  management  and  operations  systems  encompassed  by  the  DLSS 
will  continue  to  require  batch  processing  capability.  Aggregations  of  data  (batches) 
will  continue  to  be  transmitted  from  requester  to  ICPs,  to  depots,  to  transportation 
agencies,  and  to  finance  centers,  etc.,  via  AUTODIN,  and  eventually  DDN  (dedicated 
lines  for  bulk  batch  data  transmission)  for  the  foreseeable  future.  The  DLSS  must 
continue  therefore,  to  prescribe  the  transaction  types,  formats,  procedures,  and 
communications  protocols  for  batched,  inter-S/A  logistics  information  flows. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  continued  use  of  batch  processing  and  the  standardized 
exchange  of  data  in  batches. 
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Because  of  procurement  policies  in  the  Federal  Government,  this  mixture  of 
heterogeneous  (dissimilar)  equipment  can  be  expected  to  continue  in  the  future. 
However,  the  above  discussions  indicate  an  expected  increase  in  existing  require¬ 
ments  to  provide  a  level  of  inter-S/A  network  interoperability  for  the  rapid  sharing  of 
critical  and  routine  logistics  information. 

As  the  DoD  continues  to  integrate  its  operations  through  the  interorgani- 
zational  use  of  communications  networks  and  their  respective  logistics  information 
networks,  the  problems  associated  today  with  heterogeneous  equipment,  data  bases, 
and  applications  could  become  more  severe.  Resolution  of  those  problems  will 
require  planning  and  management.  The  telecommunications  and  computer 
industries  are  addressing  those  challenges  through  the  development  and 
promulgation  of  interface  standards.  The  primary  organization  responsible  for 
standards,  worldwide,  is  the  International  Standards  Organization  (ISO).  One  of  its 
committees,  which  has  representatives  from  several  U.S.  Federal  organizations 
including  DoD,  is  developing  an  architecture  for  defining  processing  functions 


performed  in  a  data  communications  system  known  as  the  Open  Systems  Intercom 
nection  (OSI)  model.  This  model  is  discussed  in  Appendix  A. 

Those  activities  and  similar  activities  of  other  organizations  to  develop  stan 
dards  for  data  administration  and  management,  data  communication,  and  data 
query  languages  will  continue  and  will  provide  the  information  user  with: 

•  Improved  identification  of,  and  access  to,  valuable  information  resources 
that  can  be  used  by  others  in  the  same  organization  or  shared  with  other 
organizations 

•  Reductions  in  unnecessary  development  of  computer  programs  when  suit 
able  programs  already  exist 

•  Simplified  software  and  data  conversion  to  new,  upgraded  hardware 
through  the  provision  of  consistent  documentation  and  standards 

•  Increased  portability  of  applications  and  acquired  skills,  resulting  in 
reduced  applications  maintenance  and  personnel  training  costs. 

A  variety  of  experimental  developments  are  underway  in  heterogeneous 
system  network  interoperability  both  in  DoD  and  in  the  commercial  marketplace. 
While  a  limited  number  of  operational  systems  currently  exists,  solutions  to  most  of 
the  technical  problems  can  be  expected  within  the  next  5  years,  and  during  that  time 
the  necessary  standards  to  provide  substantial  interoperability  will  probably  be 
defined.  Many  of  the  hardware  interface  protocol  problems  have  been  solved,  and 
distributed  data  base  interfaces  are  being  defined.  Once  these  network  interfaces 
are  established  and  operationally  proven,  the  evolutionary  development  of  a  total 
DoD  shared- logistics  information  system  network  will  face  no  technological  con 
strain  ts. 

Logistics  management  systems  and  information  are  distributed  worldwide. 
This  information,  contained  in  many  heterogeneous  systems,  needs  to  be  rapidly 
communicated  between  many  systems  and  organizations.  DoD  is  developing  a 


communications  network,  the  DDN,  to  handle  that  traffic,  but  in  time  of  mobili¬ 
zation  and/or  deployment,  communications  networks  of  other  countries  and  commer¬ 
cial  organizations  may  be  needed  to  adequately  handle  the  increased  surge  of 
logistics  information  flows. 

MODELS  Requirement:  DLSS  modernization  should  carefully 
review  existing  and  developing  communications  standards  for 
the  OSI  seven-layer  reference  model  to  facilitate  interoper¬ 
ability  in  the  logistics  community. 

DLSSO  must  take  an  active  role  in  ensuring  adherence  to 
DoD-wide  logistics  applications  data  management  standards. 

The  MODELS  concept  should  be  developed  based  on  an 
assumption  that  the  appropriate  level  of  expertise  will  be 
available. 

B.5  Data  Base  Management. 

New  functional  requirements  continue  to  evolve  and  create  a  continuous 
increase  in  the  volume  of  information  that  must  be  exchanged  among  logistics 
organizations.  However,  existing,  obsolete,  and  incompatible  file  structures  are  not 
able  to  effectively  accommodate  data  exchange  nor  handle  the  system  reorientation 
required  to  support  new  functional  requirements,  such  as  logistics  management  by 
weapons  system.  For  these  reasons,  the  trend  in  the  S/A  is  away  from  flat-file  orien 
tation  and  home-grown  DBMSs  or  file  management  systems  toward  commercially 
available  DBMSs. 

In  this  context  three  areas  need  to  be  addressed  by  MODELS: 

•  Data  element  standardization  to  more  effectively  accommodate  data  shar¬ 
ing  among  the  S/As 

•  Conformance  to  data  model  standards,  being  defined  at  the  national  and 
international  level,  when  procuring  a  DBMS 


•  Development  of  software  to  facilitate  access  to  heterogeneous  DBMSs  and 
file  structures  (distributed  data  management). 
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This  section  discusses  the  need  for  DBMSs  and  the  requirement  for  data  element 
standardization.  Data  model  standards  are  discussed  in  Part  ELI,  Chapter  C.  Distrib¬ 
uted  data  management  and  accessing  heterogeneous  DBMSs  are  discussed  in  this 
part  in  Section  B.6. 

Both  the  file  management  system  and  the  DBMS  approaches  are  supported  by 
a  large  number  of  commercial  software  packages.  For  the  file  management 
approach,  virtually  all  large-scale  computers,  minicomputers,  and  most  micro¬ 
computers  use  Common  Business  Oriented  Language  (COBOL)  and  other  high-level 
language  compilers.  The  DBMS  approach  represents  hundreds  of  individual  applica¬ 
tion  packages.  Factors  to  be  considered  by  an  individual  organization  in  determin¬ 
ing  which  approach  should  be  used  include  organizational  structure,  hardware 
constraints,  software  constraints,  support  staff,  performance  requirements,  cost, 
query-  and  report- generation  requirements,  security,  data  sharing  environment, 
data  usage  pattern,  data  volume,  and  others. 

The  file  management  approach  involves  development  of  specially  designed 
application  software  programs.  Those  software  programs  provide  all  the  needed 
application  functions  and  are  usually  written  in  COBOL  or  another  high-level 
programming  language.  Data  records  having  simple  and  common  formats  are 
combined  into  distinct  files.  The  programming  staff  develops  each  application 
separately,  working  out  program  logic  and  file  designs  that  seem  convenient  and 
effective  for  the  specific  required  processing.  The  programming  staff  must  be  aware 
of  the  appropriate  file  access  methods  and  must  support  relationships  between  files 
by  special  programming  procedures.  In  most  cases,  the  file  management  approach 
relies  heavily  on  batch  mode  processing. 

The  DBMS  approach  can  use  a  commercially  available  DBMS.  A  DBMS  is  a 
software  system  allowing  multiple,  independent  users  concurrent  access  to  a  shared 
data  base.  A  data  base  consists  of  an  interrelated  set  of  data  stored  together  with 


controlled  redundancy  to  serve  one  or  more  applications.  The  DBMS  provides  a 
controlled  approach  for  adding  new  data  and  modifying  and  retrieving  existing  data. 
That  approach  provides  a  degree  of  data  independence  in  that  data  can  be  accessed 
logically  without  knowing  any  special  physical  access  method  or  procedure  support¬ 
ing  the  data  access. 

A  particularly  important  consideration  in  data-base  design  is  to  store  the  data 
so  it  can  be  used  for  a  wide  variety  of  applications  and  can  be  changed  easily  and 
quickly.  In  file-oriented  systems  it  is  very  difficult  to  change  the  way  data  are  used. 
Modifications  can  set  off  a  chain  reaction  of  changes  to  existing  programs  and  can  be 
exceedingly  expensive.  When  a  single  set  of  data  items  serves  a  variety  of  applica¬ 
tions,  different  application  programs  perceive  different  relationships  between  the 
data  items.  A  data  base  used  for  many  applications  can  have  multiple  intercon¬ 
nections  among  the  data.  Use  of  data-base  techniques  can  permit  users  to  employ 
the  data  in  ways  that  cannot  and  need  not  be  precisely  anticipated  by  the  system 
designers. 

Today,  DBMS  vendors  provide  a  complete  set  of  integrated  tools  along  with  the 
basic  DBMS  package.  These  tools  include  data  dictionary,  teleprocessing  monitor, 
query  facility,  report  writer,  application  development  facility,  and  special-purpose 
application  packages  built  upon  the  DBMS.  Integration  tools  can  make  the  DBMS 


environment  much  easier  to  use. 

End-user-oriented  data  bases  are  very  good  at  extracting  a  small  amount  of 
data  from  a  large  data  base  and  quickly  presenting  the  results  to  the  user. 
Data-processing-oriented  DBMSs  are  best  in  data  structuring  capabilities  and 
provide  performance-tuning  capabilities  for  choosing  access  methods  and  physical 
storage  strategies  most  appropriate  for  the  application. 

Much  redundancy  exists  in  data  that  is  used  throughout  DoD,  and  the  same 
item  of  data  is  often  defined  slightly  differently  by  the  various  S/As.  Correcting  the 
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imprecision  in  the  way  data  is  defined  and  used  must  go  hand-in-hand  with  the 
design  and  stage-by-stage  integration  of  data  bases.  A  DLSS  data  dictionary  defin¬ 
ing  all  data  items  that  are  in  use  in  DoD  logistics  must  continue  to  be  expanded, 
based  initially  on  the  current  LOGDRMS. 

A  data  dictionary  is  a  central  repository  of  information  about  the  entities,  the 
data  elements  representing  the  entities,  the  relationships  between  the  entities,  and 
their  origins,  meanings,  uses,  and  representation  formats.  The  benefits  of  using  a 
data  dictionary  are  related  to  the  effective  collection,  specification,  and  management 
of  the  total  data  resources  of  an  organization.  A  data  dictionary  should  help  a  data 
base  user  in: 

•  Communicating  with  other  users 

•  Controlling  data  elements  in  a  simple  and  effective  manner,  that  is, 
introducing  new  elements  into  the  systems  or  changing  descriptions  of 
existing  elements 

•  Reducing  data  redundancy  and  inconsistency 

•  Determining  the  impact  of  changes  to  data  elements  on  the  total  data  base 

•  Centralizing  the  control  of  the  data  elements  as  an  aid  to  data  base  design 
and  to  expanding  the  design. 

The  data  dictionary  can  be  used  to  standardize  the  use  of  data  or  simply  to 
disseminate  information  about  the  use  of  data.  If  the  sharing  of  data  is  wide  and 
prevalent,  it  will  be  necessary  to  utilize  the  data  dictionary  to  provide  for  standard¬ 
ization,  where  appropriate.  On  the  other  hand,  if  only  minimal  data  sharing  is 
necessary,  the  requirement  for  standardization  is  minimized  and  more  emphasis  will 
be  placed  on  dissemination  of  information  about  data. 

Within  the  DLSS,  the  LOGDRMS  program  encompasses  development  of  a 
standard  data  dictionary  to  support  information  interchange  in  the  logistics  commu 
nity.  DLSC  establishment  of  a  master  logistics  data  directory  has  been  proposed.  In 
that  case,  data  elements  would  be  classified  and  described  using  the  same  discipline 


and  procedures  used  to  establish  an  item  of  supply  in  the  system.  This  master 
logistics  data  directory  concept  would  identify: 

•  The  kinds  of  logistics  data  that  exist 

•  The  data  location 

•  The  organization  responsible  for  the  data  integrity  and  update 

•  The  users  authorized  access  to  the  data 

•  The  directory  interrogation  procedures 

•  The  data  source  input  format. 


MODELS  Requirement:  The  MODELS  concept  recognizes  the 
use  of  modern  DBMS  technology  by  the  S/As  and  must  provide 
for  procedures  to  standardize  data  element  definitions  in  the 
S/As.  In  the  interim,  data  dictionaries  should  be  established  to 
facilitate  inter-S/A  data  element  translations.  (Correlates  to 
MODELS  Requirement  —  Part  I,  Chapter  A,  Section  A.l, 
page  1-11  and  Part  II,  Chapter  B,  Section  B.l,  Page  11-12.) 


B.6  Distributed  Data  Base  Management. 


A  DDBMS  is  the  software  system  that  manages  data  within  the  data  base  that 


is  distributed  in  different  locations  throughout  a  computer  network.  Distributed 


data  base  management  technology  is  the  logical  merging  of  two  trends  in  computing: 


DBMS  and  data  communications  networks.  A  distributed  data  base  environment  is 


an  integrated  data  base  that  is  built  within  a  computer  network  rather  than  within  a 
single  computer.  Requirements  of  a  true  distributed  data  base  include  the  ability  to: 


•  Distribute  data  files  between  at  least  two  computer  nodes  while  the  location 
of  the  data  is  transparent  to  the  user 

•  Retain  data  file  relationships  (even  when  the  files  are  located  at  separate 
network  nodes) 

•  Ensure  transaction  integrity  in  the  distributed  environment. 

There  are  two  types  of  DDBMSs,  heterogeneous  and  homogeneous.  The  hetero 
geneous  DDBMS  prototypes  under  development  permit  only  retrieval  of  data 


distributed  throughout  the  network,  whereas  a  homogeneous  DDBMS  will  support 
both  retrieval  and  update  operations. 

Through  its  data  dictionary,  a  DDBMS  knows  which  data  are  where,  what  the 
logical  and  physical  structures  of  those  data  are,  and  how  to  access  them.  A  hetero¬ 
geneous  DDBMS  consists  of  a  global,  or  neutral,  data  definition  language  that 
describes  common  data  and  a  global,  or  neutral,  data  manipulation  language  that 
manipulates  those  descriptions  to  provide  access  to  the  data  whether  they  are  stored 
in  a  DBMS  or  under  a  specialized  file  control  system. 

The  features  that  distinguish  a  heterogeneous  DDBMS  are  defined  as: 

•  Interconnection  of  dissimilar  DBMSs 

•  Use  of  dissimilar  operating  systems  to  support  the  collection  of  DBMSs 

•  Use  of  dissimilar  host  computers  within  the  network  to  serve  a  variety  of 
functions  (e.g.,  addressing,  formatting,  etc.). 

An  issue  associated  with  this  last  feature  is  that  of  gateways  between  networks.  A 
gateway  provides  the  capability  of  passing  data  between  connected  networks  and 
resolves  crossover  problems.  Gateway  functions  can  be  performed  within  the  host 
computer  of  the  DBMS,  by  front-end  processors,  or  by  centralized  processors,  such  as 
DAAS. 

Heterogeneous  DDBMS  technology  is  still  in  its  infancy.  A  recent  survey 
reveals  that  only  experimental  prototype  systems  exist.  No  operational  systems 
exist  that  are  truly  distributed  in  the  heterogeneous  DDBMS  sense.  Current 
DDBMS  efforts  are  discussed  in  Part  EH,  Chapter  C.  As  of  today,  there  are  still  many 
unresolved  problems  in  the  heterogeneous  DDBMS  area: 

•  Structured-Data  Transfer  Protocols.  File  transfer  protocols  have  been 
developed  to  transform  data  from  a  specific  existing  format  to  another 
specific  target  format.  Structures  and  pointers  are  manipulated  to  create 
the  new  data  format  for  the  transfer.  More  research  is  needed  to  provide 
software  capable  of  fully  supporting  the  migration  of  data  among  the 
multiple  computers  of  a  DDBMS  while  preserving  the  correct  data  seman 
tics. 


•  Common  Global  Data  Model.  Research  and  standardization  are  needed  in 
the  development  of  a  common  global  data  model  to  accommodate  merging 
extracted  data  coming  from  different  DBMSs  with  different  data  models. 

•  User-Friendly  Interfaces.  Interfaces  should  include  not  only  an  easy-to-use 
data  access  and  manipulation  language  but  also  easy-to-use  resultant  data 
integrated  in  a  format  that  is  readable  and  can  be  manipulated  by  other 
software  for  analysis,  modeling,  or  graphics  display. 

•  Semantic  Integrity  of  Data.  Data  existing  at  different  sites  might  have 
different  semantics;  for  example,  a  field  called  Unit  of  Issue  might  have 
different  unit  semantics,  with  a  wholesale  site  using  'gross’  as  a  unit  and  a 
retail  site  using  'each’  as  a  unit.  Data  within  the  network  must  be  consis¬ 
tent  and  correct. 

•  Multi-Site  Updates.  For  data  bases  that  are  replicated,  an  update  to  one 
data  base  involves  updates  to  all  the  repeated  parts  without  a  long  delay 
time.  Although  many  algorithms  exist  to  solve  this  problem,  more  research 
is  needed  to  ensure  consistency  of  data  as  well  as  efficient  operation  within 
the  network. 

•  Distributed  Dictionary  and  Directory  Management.  Distributing  and 
managing  the  dictionary/directory  information  within  a  DDBMS  can  be 
done  in  many  ways,  with  each  separate  way  having  advantages  and  disad¬ 
vantages.  Evaluation  of  these  various  methods  and  efficient  ways  of 
handling  dictionary/directory  information  in  case  of  site  failure  remains  a 
challenging  topic. 

While  full-scale  heterogeneous  distributed  data  base  processing  will  probably 
not  be  available  until  1990  —  1995,  the  logistics  community  does  not  have  to  wait  for 
the  availability  of  this  technology  before  using  the  concept.  The  DLSS  have  already 
led  to  the  development  of  a  common  set  of  information  interchange  standards  that 
provide  the  basis  for  interconnecting  logistics  data  bases.  It  is  likely  that  these 
standards  will  simplify  the  implementation  of  distributed  data  base  access.  In 
addition,  the  types  of  on-line  data  base  access  initially  anticipated  for  logistics 
applications  will  be  restricted,  for  example,  to  inquiries  of  requisition  status,  item 
availability,  and  catalog  information.  Here  again,  these  restrictions  simplify  the 
required  capabilities  of  the  heterogeneous  DDBMS.  For  these  reasons,  it  is  likely 
that  the  technology  to  meet  many  of  the  needs  of  the  DoD  logistics  community 
already  exists. 


MODELS  Requirement:  The  MODELS  concept  must  be 
structured  to  take  advantage  of  the  emerging  DDBMS  tech¬ 
nology.  Existing  DDBMS  technology  should  be  reviewed  to 
determine  its  ability  to  address  the  needs  of  the  logistics 
community. 

B.7  Data/Voice/Video  Communications. 

Many  information  industry  experts  believe  that  the  integration  of  data,  voice, 
and  video  technology  is  essential  to  bringing  information  management  to  the  next 
generation  of  users  —  those  who  have  little  patience  for  cursor  keys,  rigid  command 
structures,  and  keyboard  data  entry.  Major  computer  and  communication  organi¬ 
zations,  such  as  American  Telephone  and  Telegraph  (AT&T)  and  IBM,  want  to  make 
computer  system  interfaces  that  are  as  easy  to  learn  and  use  as  the  telephone  and 
television. 

Integrated  data/voice  technology  encompasses  several  applications  including: 
(1)  speech  recognition  and  synthesis,  in  which  a  telephone  caller  can  receive  a  pre¬ 
stored  voice  message  dictated  specifically  for  him/her  and  released  only  on  voice 
recognition  of  their  name  or  a  preestablished  voice  password,  and  the  subsequent 
voice  storage  and  playback  of  any  message  the  caller  leaves  in  response  to  the  initial 
conversation  (a  product  with  the  potential  to  stop  much  of  the  telephone  "tag”  that 
occurs  today);  (2)  speech  recognition  control  of  computer  applications  (e.g.,  placing  a 
formula  to  calculate  the  sum  of  the  monthly  entries  in  the  spreadsheet  cell  after  the 
December  entry  and  calculate  the  totals);  (3)  text-to-speech  conversion  in  which  on¬ 
line  help  facilities  are  voice  actuated  to  speak  the  help  lessons  or  messages  typed  at 


one  location  (electronic  mail)  are  voiced  to  the  receiver  at  a  remote  location,  for 
example,  for  an  electronic  mail  requisition  status  inquiry;  and  (4)  speech-to-text 
conversion  in  which  the  computer  user  dictates  the  information  for  a  memo  or 
message  directly  to  the  computer  rather  than  having  to  enter  it  through  a  keyboard. 


11-34 


.■ VvvYvV  v  vv'-.v.  \  -w-  ^  v<  -  .y. 


Integrated  data/video  technology  encompasses  an  even  larger  spectrum  of 
potential  applications.  Those  applications  include  self-training  and  simulation 
materiels  of  all  types,  pictures  of  items  to  be  purchased,  detailed  visual  maps/ 
pictures  of  places  being  traveled  to  for  complete  orientation  to  streets  and  buildings, 
and  electronic  transmission  of  publications/catalogs,  including  charts,  graphs,  and 
pictures. 

The  final  integration  of  data/voice/video  brings  all  of  these  various  applications 
into  their  full  potential.  Applications  may  include  picture  telephones  for  remote 
face-to-face  purchase  negotiations,  voice  requests  to  the  national  catalog  system  for 
identification  of  unknown  items  received  in  a  shipment,  and  voice  requests  to  an  ICP 
to  visually  review  potential  substitutes  for  a  part  currently  out-of-stock.  The 
opportunities  offered  by  these  emerging  technologies  are  limited  only  by  the  imagi¬ 
nations  of  the  potential  users. 

The  integration  of  these  technologies  is  still  in  its  infancy;  however,  with 
multiple  small,  innovative  firms  pushing  the  limits  of  existing  technology  and  large 
organizations  such  as  AT&T  and  IBM  fully  recognizing  the  potential  in  the  commer 
cial  marketplace,  one  can  expect  that  the  1990  —  1995  time  frame  will  see  some,  if 
not  all  of  those  capabilities  commercially  available.  Appropriate  use  of  these 
technologies,  like  the  telecomputing  technologies  in  use  today,  will  require  the 
development  and  publication  of  communication  standards  and  procedures.  The 
capabilities  offered  by  these  technologies  will  do  much  to  further  increase  inter-S/A 
interfaces  as  they  bring  a  whole  new  generation  of  users  into  daily  use  of  telecom¬ 
puting  capability.  As  the  official  DoD  instrument  responsible  for  establishing 
logistics  standard  systems,  the  DLSS  will  need  to  address  how  these  emerging 
technologies  can  best  be  incorporated  into  improving  logistics  operations  and 
management.  It  is  critical  to  the  MODELS  concept  —  and  mandatory  if  DoD  is  to 
ensure  long-term  stability  of  standard  logistics  communications  —  that  the  DLSS 


have  the  flexibility  to  allow  the  S/As  to  progress  at  different  rates  in  the  implemen¬ 
tation  of  new  technologies. 

MODELS  Requirement:  The  MODELS  concept  must  be  struc¬ 
tured  to  accommodate  rapidly  evolving  advanced  computer 
and  communication  technologies. 
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CHAPTER  C:  LOGISTICS  MANAGEMENT  INFORMATION  REQUIREMENTS 


The  MODELS  project  is  one  of  many  ongoing  OSD  and  Services/DLA  initia¬ 
tives  to  improve  logistics  management.  Congressional  oversight  on  multi-billion 
dollar  weapons  system  developments  and  operation  budgets,  billions  of  dollars  in 
spare  parts  inventories,  and  perceived  waste  in  DoD  disposal  of  near-new  parts  have 
resulted  in  the  placement  of  great  emphasis  on  better  management  of  DoD  logistics 
programs.  More  usable  and  timely  information  must  be  available  to  various  levels  of 
logistics  managers  to  improve  planning  and  decision-making. 

This  chapter  discusses  the  following  logistics  management  initiatives  that  are 
responsible  for  establishing  the  types  of  information  that  must  be  exchanged  as  well 
as  resetting  the  tone  of  logistics  management  philosophy  and  processes: 

•  Secondary  item  weapons  system  management 

•  Issue  and  transportation  priority  coding 

•  In-transit  visibility 

•  Contract-related  information  exchange. 

C.l  Weapons  System  Management  Issues. 

The  DoD  Supply  Management  Policy  Group  (SMPG)  has  defined  Secondary 
Item  Weapons  System  Management  (SIWSM)  in  terms  of  13  functional  require¬ 
ments.  The  objective  of  the  SIWSM  initiative  is  to  enable  DoD  to  manage 
inventories  of  spare  and  repair  parts  to  achieve  improved  materiel  readiness  and 
performance  goals  for  each  weapons  system.  SIWSM  will  require  a  realignment  of 
both  logistics  processes  and  operational  objectives.  As  a  result,  it  will  have  a  tremen 
dous  impact  on  the  modernization  of  the  DLSS.  The  13  SIWSM  functional 


requirements,  as  approved  by  Secretary  Weinberger,  and  discussion  of  their  impact 
on  DLSS  follows. 

•  Application  Files.  The  S/As  should  maintain  data  files  reflecting  full 
indenture  breakdown  for  all  supported  weapons  systems.  The  flies  will  be 
designed  for  use  in  requirements  determination  and  will  reflect  relative 
priority  between  items  with  respect  to  the  next  higher  assembly  and 
ultimately  to  the  weapons  system. 

•  Stock  Levels  by  Weapons  System.  The  S/As  should  develop  capability  to 
stratify  the  segments  (e.g.,  stock  safety  level  and  economic  order  quantity) 
of  inventory  requirements  by  weapons  system  for  both  peculiar  and  common 
items.  Common  items  should  be  stratified  according  to  usage,  by  applica¬ 
tion. 

•  Multiechelon  Optimization  Models.  The  S/As  should  develop  inventory 
requirements  models  that  will  generate  requirements  for  wholesale,  inter¬ 
mediate,  and  consumer  levels  to  support  weapons  systems  availability  goals 
at  minimum  cost.  This  requirement  directs  a  shift  from  the  traditional 
objective  of  meeting  fill-rate  goals  to  the  objective  of  meeting  weapons 
systems  operational  availability  goals. 

•  Integrated  Initial! Replenishment  Spares  and  Repair  Parts  Computations. 
The  S/As  should  ensure  that  allowance  computations  for  initial  provision¬ 
ing  are  consistent  with  the  computations  of  replenishment  requirements. 

•  Asset  Visibility.  The  Integrated  Materiel  Manager  (IMM)  should  have  DoD- 
wide  asset  visibility  down  to  the  lowest  supply  echelon.  Within  the  S/As, 
the  full  asset  visibility  required  does  not  currently  exist.  This  is  particularly 
true  of  Service-owned  assets  managed  by  another  Component  at  the 
wholesale  level.  Also,  visibility  of  assets  held  in  the  industrial  funds  is 
inadequate. 

•  Demand/Usage  Reporting.  The  S/As  should  implement  the  capability  to 
code  and  record  demands  and  maintenance  usage  data  by  weapons  system. 
The  procedures  for  generating  requisitions  will  have  to  be  modified  to 
efficiently  and  accurately  capture  weapons  system  applications  at  the 
source.  The  information  systems  at  each  supply  echelon  will  have  to  be 
modified  to  perpetuate  these  data. 

•  Inter-S/A  Data  Exchange.  The  S/As  should  implement  the  capability  for 
exchanging  end-item  program  and  application  data,  secondary  item 
demand  and  usage  data,  and  information  on  resupply  times. 

•  Performance  Tracking.  The  S/As  should  implement  performance  tracking 
systems  to  measure  supply  and  operational  availability  performance  by 
weapons  system.  Standardized  DoD-wide  performance  measurement 
criteria  for  supply  and  operational  availability  performance  by  weapons 
system  should  be  incorporated  into  DLSS-expanded  procedures. 
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•  Asset  Positioning.  The  S/As  should  implement  the  capability  to  position 
items  essential  to  weapons  systems  so  that  requisition  response  time  is 
minimized.  The  Services  are  required  to  accomplish  this  within  their  own 
storage  and  distribution  systems,  while  DLA  will  accomplish  it  within  the 
DoD-wide  storage  and  distribution  system  to  include  Service-operated  sites. 
Optimal  positioning  for  reparable  items  should  consider  the  location  of  both 
storage  and  repair  facilities. 


•  Redistribution.  The  S/As  should  implement  the  capability  to  redistribute 
essential  weapons  system  items  on  a  system-wide  basis  to  achieve  weapons 
system  readiness  objectives.  This  capability  should  be  developed  in  conjunc¬ 
tion  with  the  requirements  for  asset  visibility  discussed  above. 

•  Development  of  Planning,  Programming,  and  Budgeting  System  (PPBS) 
Inputs.  The  S/As  should  implement  the  capability  to  prepare  their  Program 
Objective  Memoranda  (POMs)  and  secondary  item  budget  submissions  on  a 
weapons  system  basis. 

•  Budget  Execution.  Tne  S/As  should  implement  the  capability  to  monitor 
budget  execution  on  a  weapons  system  basis.  This  capability  should  be 
consistent  with  the  systems  created  to  formulate  budget  submissions  on  a 
weapons  system  basis. 

•  Balancing  Resources.  The  S/As  should  implement  the  capability  to 
determine  the  optimal  allocation  of  resources  among  procurement,  repair, 
and  distribution  to  achieve  maximum  weapons  system  effectiveness. 

MODELS  Requirement:  The  MODELS  concept  requires  a 
highly  efficient  and  reliable  system  of  telecommunications  and 
gateway  processors  to  support  inter-S/A  queries  and  transfer  of 
various  types  of  weapons  system-related  data.  Any  data 
exchange  programs  to  support  weapons  systems  must  be 
designed  to  accommodate  classified  data. 

C.2  Priority  Issues. 

A  second  change  in  DoD-wide  logistics  management  information  requirements 
relates  to  the  Uniform  Materiel  Movement  and  Issue  Priority  System  ( I'MMIPSi  A 
recently  completed  study  of  the  UMMIPS  by  the  Logistics  Systems  Analysis  Office 
(LSAO)  found  that  a  total  cost  avoidance  of  $117  million  was  achieved  through  the 
S/A’s  air  challenge  programs  downgrading  of  nearly  200,000  air  eligible  shipment  - 
to  surface  modes.  The  LSAO  concluded  that  the  customer  is  reallv  concerned  th. ..it 
whether  he/she  will  get  the  item  allocated  rather  than  how  rnanv  d  iv-  ;t  mk*  -  * 
arrive  after  it  is  issued.  The  LSAO  recommenn.-  that  the  office  ,t  \o*  ])-•; 
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Assistant  Secretary  of  Defense  (Logistics  and  Materiel  Management) 
[ODASD(L&MM)]  should  promulgate  new  and  revised  policies  to  incorporate  the 
flexibility  to  accommodate  a  dual  supply-issue  and  transportation  priority  system. 

The  MODELS  team  interviews  and  operational  reviews  found  similar  condi 
tions  both  at  the  shipping  centers  (depots)  and  from  comments  expressed  bv 
customers.  A  two-priority  system  is  needed  to  separately  reflect  issue  priority  and 
transportation  priority  within  the  requisition  transaction. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
for  modernized  DLSS  procedures  and  transaction  data  ele 
ments  to  accommodate  implementation,  through  UMMIPS.  of 
separate  issue  and  transportation  priority  coding  systems. 

C.3  In  Transit  Visibility. 

As  the  cost  of  maintaining  the  armed  forces  has  grown  over  the  years,  the 
investment  in  stock  levels  has  become  an  increasingly  critical  issue  Depot  stocks 
are,  with  some  exceptions,  maintained  in  CONUS.  Retail  stocks  should  be  main 
tained  at  the  minimum  level  consistent  with  a  responsive  supply  and  transportation 
system.  One  critical  problem  to  effective  stock-level  management  is  the  lack  of 
common  data  in  two  of  the  DLSS  —  MILSTAMP  and  MILSTRIP 

Within  the  MILSTAMP  procedures  and  related  transportation  systems,  identi 
fication  of  cargo  being  moved  is  by  a  TCN  With  some  exceptions,  such  as  for  safetv, 
financial,  or  security  considerations,  transportation  management  is  not  concerned 
with  "what  is  in  the  box  "  However,  others  need  to  know  what  is  moving,  when  it 
will  be  delivered,  and  similar  info  .nation  about  the  cargo  Logistics  information 
requirements  in  cargo  movement  are  not  clearlv  identified  and  varv  depending  ri 
the  position  of  the  activtv  requesting  'he  .ntorm.it;  01  w  ■  train  ?  he  ,  >g  . 
organization 
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transportation),  these  data  are  available  by  cross-reference  of  requisition  number  to 
TCN  at  the  origin  of  the  shipment  where  the  materiel  enters  the  transportation 
[Military  Standard  Transportation  and  Movement  Procedures  (MILSTAMP)] 
system.  The  problem  is  compounded  by  the  consolidation  process  necessary  to  utilize 
transportation  assets  effectively  and  reduce  transportation  costs.  The  large  volumes 
of  data  also  have  a  direct  impact  on  data  availability.  The  shipper,  such  as  a  depot, 
normally  consolidates  a  number  of  requisitions  under  one  TCN.  That  TCN  may  in 
turn  be  consolidated  with  other  TCNs  at  a  container  consolidation  point,  an  aerial 
port,  or  another  node  in  the  transportation  network.  Each  level  of  consolidation 
further  compounds  the  problem  of  specific-item  visibility. 

In  CONUS  surface  and  air  shipments,  only  the  shipping  activity  knows  what 
has  been  shipped  and  only  the  commercial  carrier  knows  where  the  shipment  is 
during  transit.  While  advance  copies  of  GBLs  and  other  forms  of  notification  are 
forwarded  to  receiving  activities,  in  many  cases  the  shipment  moves  faster  than  the 
notification. 

In  transit  visibility  has  been  the  subject  of  continuing  dialog  within  DoD  for 
many  years.  Various  elements  of  DoD  have  indicated  a  need  for  shipment  and  item 
tracking  information.  Three  major  issues  are  involved: 

•  Responsibility  —  Who  needs  certain  information  data? 

•  Level  of  detail  -  What  information  is  needed? 

•  Availability  -  How  is  the  information  to  be  provided0  (This 
issue  presents  both  processing  system  and  communications  prob 
lems.) 

Although  one  cannot  expect  the  MODELS  project  to  solve  all  the  issues  in  this 
area,  it  can  and  should  provide  a  framework  for  their  resolution  It  is  very  important 
that  the  MODELS  system  concept  recognize  these  issues  and  be  structured  to  con 
tribute  to  their  resolution 
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MODELS  Requirement:  Modernized  DLSS  procedures  should 
improve  on  existing  supply-transportation  interfaces  by 
providing  specific-item  visibility  during  the  shipment  process. 
(Correlates  to  MODELS  Requirement  —  Part  I,  Chapter  E, 
Section  E.2,  page  1-88.) 


C.4  Contract-Related  Information  Exchange  . 


On  10  January  1986,  the  Deputy  Assistant  Secretary  of  Defense  (L&MM) 
issued  a  memorandum  to  the  Services  to  initiate  a  joint  MILSCAP  Improvement 
Program  to  automate  the  interchange  of  contract-related  data  throughout  the  DoD 
at  the  earliest  opportunity  —  even  before  MODELS  is  complete.  This  objective 
includes  full  electronic  interchange  of  required  contractual  data  between  Defense 
Contract  Administration  Service  Regions  (DCASRs)  and  ICPs,  and  subsequent 
dissemination  to  depots  for  destination  acceptance  reporting.  Implementation  of  this 
capability  will  have  a  significant  impact  both  upon  Military  Standard  Contract 
Administration  Procedures  (MILSCAP)  and  MILSCAP  information  transmission 
formats. 

A  major  drawback  to  the  current  MILSCAP  information  data  structure  is  the 
restricted  80-column  card  format  that  often  requires  the  preparation  of  multiple 
trailer  cards.  The  opportunity  now  exists  to  take  advantage  of  advanced  processing 
and  telecommunications  capabilities  to  expand  the  record  size  beyond  80  columns  to 
accommodate  a  large  text  field  of  contract-related  descriptive  information. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  electronic  exchange  of  large  text-fields  of  contract-related 
information.  (Correlates  to  MODELS  Requirement  —  Part  I, 

Chapter  C,  Section  C.2.a,  page  1-37.) 
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CHAPTER  D:  INFORMATION  RESOURCES  MANAGEMENT 
INPUT  CONSIDERATIONS 


D.l  Objectives. 

Congress  has  mandated  that  each  Federal  Agency  establish  Information 
Resources  (IRM)  planning.  In  the  DoD,  responsibility  for  preparation  of  the  IRM 
Plan  is  assigned  to  the  Comptroller.  The  Comptroller  in  turn  collects  IRM  plan 
inputs  from  each  organization  involved  in  the  formal  development  of  information, 
both  automated  and  nonautomated.  This  section  addresses:  (1)  why  DLSSO  should 
provide  a  logistics-oriented  input  to  the  IRM  planning  process,  and  (2)  what  informa¬ 
tion  should  be  included  in  a  DLSSO  IRM  input  document. 

D.2  The  Need  for  Planning. 

It  would  be  unthinkable  to  build  a  complex  weapons  system  without  an  overall 
plan.  The  design  and  development  of  a  weapons  system,  such  as  a  fighter  aircraft, 
begins  with  an  overall  plan  that  defines  the  desired  performance  of  the  completed 
aircraft.  To  achieve  these  broad  performance  goals  the  design  is  divided  into 
functional  areas:  power  plants  for  propulsion,  airframes  for  the  aircraft  structure, 
and  control  systems  for  navigation,  weapons  delivery,  flight  controls,  etc.  Each  of 
those  functional  areas  is  assigned  specific  performance  objectives  that  contribute  to 
the  performance  goals  of  the  completed  aircraft. 

This  design  approach  permits  a  highly  complex  problem  to  be  divided  into 
manageable  parts.  Each  part  can  then  be  designed  independently  to  meet  its  specific 
performance  objectives.  Even  though  the  design  effort  for  each  part  proceeds 
independently,  the  overall  plan  ensures  that  the  parts  will  fit  into  the  overall 
system. 


The  design  and  development  of  a  modern  information  system  is  no  less  compli 
cated  than  those  of  the  fighter  aircraft.  IRM  for  an  organization  or  a  functional  area 
(e.g.,  logistics)  can  be  used  to  develop  a  plan  that  defines  and  controls  the  design  and 


development  of  information  resources  and  systems5  by: 


•  Defining  the  goals  of  the  information  system  and  associating  those  goals 
with  the  goals  and  mission  of  the  function/organization  that  the  system 
supports. 


•  Defining  specific  objectives  of  subsystems  and  associating  those  objectives 
with  the  goals  of  the  total  system. 


•  Prioritizing  subsystems  in  terms  of  resource  requirements  and  associated 
goals. 


•  Evaluating  subsystem  performance  in  meeting  specific  objectives. 


Modern  information  systems  that  employ  distributed  processing,  electronic  inter 


change  of  data,  and  shared  data  bases  must  employ  this  kind  of  top-down  planning  to 


be  successful. 


D.3  Background  of  Agency  IRM. 


The  Federal  IRM  Review  Program  is  a  Government-wide  program  established 


to  support  improvements  in  Federal  information  resources  management  and  to  meet 


certain  requirements  of  the  Paperwork  Reduction  Act  of  1980,  Public  Law  96-511. 


Specifically,  the  program  was  designed  in  response  to  requirements  that  agencies 


review  their  information  management  policies  and  procedures  to  ensure  they  were 


adequate.  The  Office  of  Management  and  Budget  (OMB),  with  assistance  from  GSA. 


is  directed  to  report  to  Congress  on  how  well  agencies  are  doing 


The  Paperwork  Reduction  Act  requires  that  each  agency  appoint  an  official  to 


periodically  review  major  informations  systems  and  ensure  that  data  collection  and 
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reporting  burdens  are  minimized,  that  systems  do  not  overlap  or  duplicate  functions, 
and  that  information  system  acquisitions  are  cost  effective. 


D.4  IRM  Directives,  Scope,  and  Definition. 

OMB  Circular  No.  A-130,  Management  of  Federal  Information  Resources, 
implements  OMB’s  authority  under  the  Paperwork  Reduction  Act.  The  Federal 
Information  Resources  Management  Regulation  (FIRMR)  issued  by  GSA  is  the 
primary  regulation  governing  information  resource  management  and  information 
systems  acquisition.  To  supplement  the  FIRMR,  GSA  also  published  the  Federal 
Information  Resources  Management  Review  Program,  An  Executive  Guide  and  the 
Strategic  Information  Resources  Management  Planning  Handbook. 

DoDD  7740.1,  20  June  1983,  establishes  the  IRM  Program  within  DoD.  That 
directive  applies  to  the  OSD,  the  Military  Departments,  the  Organization  of  the 
Joint  Chiefs  of  Staff  (OJCS),  the  Unified  and  Specific  Commands,  and  the  Defense 
Agencies. 

DoDD  7740.1  provides  a  rather  broad  definition  of  IRM: 

The  policy,  action,  or  procedure  concerning  information  (both 
automated  and  nonautomated)  that  management  establishes 
to  serve  the  overall  current  and  future  needs  of  the  organi 
zation.  IRM  policy  and  procedures  would  address  such  areas  as 
availability,  timeliness,  accuracy,  integrity,  privacy,  security, 
auditability,  ownership,  use.  and  cost  effectiveness  of  informa 
tion. 

D.5  DoD  IRM  Program  Goals. 

The  IRM  Systems  Directorate,  Office  of  the  Assistant  Secretary  ..f  |)cf.  no 
(Comptroller i.  promulgated  five  TR-M  goals  for  Dot)  in  late  I'tM 

•  Improve  DoD  mission  operations  and  decision  making  'hough  ’to  .  ft,  ,  • 
and  economic  development  and  use  of  i  n  form  at  inn 

•  Integrate  Du  |»  information  management  otr.  to  Mir  mg  h  .  t 

consistent  plans.  programs,  policies,  ind  pro,  e,),.,.- 

•  Acquire  and  u so  information  'echno|..gv  *>  out  '  •  "■■■•  -  a  t  •  1 1  •  ■  •  .  .  ,  . 

productivity  ind  program  mao  igement 


•  Strengthen  life  cycle  management  of  information  systems 

•  Foster  general  awareness  of  the  value  of  information  and  its  associated 
costs. 

These  goals  have  clear  implications  for  the  MODELS  project  and  the  DoD  logistics 
community. 

An  overall  plan  is  required  to  describe  the  interfaces  in  terms  of  common  data 
element  definitions,  telecommunication  protocols,  DBMS  interface  standards,  secu¬ 
rity  access  procedures  between  systems,  and  electronic  data  transmission  formats 
and  to  provide  a  coordinating  process  for  the  development  of  these  interface  systems. 
The  objective  is  not  to  infringe  on  the  creativity  of  the  individual  Service  to  produce  a 
system  to  meet  its  specific  needs  but  rather  to  define  a  framework  to  ensure  that  the 
systems  developed  by  DoD  Components  operate  efficiently  within  the  total  DoD 
logistics  system.  This  approach  optimizes  the  effectiveness  of  the  total  logistics 
system. 

MODELS  Requirement  Individual  S/A  logistics  systems  need 
to  be  designed  with  the  total  DoD  logistics  community  in  mind. 

An  overall  DoD  logistics  systems  modernization  plan  should  be 
formally  prepared  and  regularly  updated  as  part  of  the 
MODELS  continuing  modernization  process. 

I). 8  DoD  Logistics  Community  IRM. 

7’he  purpose  of  the  IRM  plan  is  to  examine  current  areas  of  application,  identify 
opportunities  for  improvement,  associate  applications  with  specific  Do I)  goals,  track 
progress  in  meeting  specific  application  objectives,  and  monitor  costs  associated  with 
application  development.  As  a  management  tool,  the  plan  provides  a  means  for 
projecting  requirements  to  avoid  crisis  management,  defining  areas  of  respon 
ability,  assigning  responsibility  and  tracking  performance  against  specific  goals 
An  IRM  plan  outline  is  presented  i n  \ ppendi x  B 
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To  accomplish  these  objectives  DLSS  inputs  to  the  DoD  IRM  Plan  can  cover 
several  levels  of  the  DoD  organization.  One  decision  that  must  be  made  by  the 
ODASD(L&MM)  is  the  extent  of  functional  and  organizational  coverage  of  the  DLSS 
inputs.  To  illustrate  this  question,  the  following  discussion  presents  two  possible 
approaches  to  developing  IRM  inputs  for  the  DoD  logistics  community:  documen¬ 
tation  covering  only  DLSS  projects  and  documentation  covering  both  DLSS  and  DoD 
Component  logistics  projects. 

IRM  plan  inputs  for  DLSS  projects  only  is  the  simplest  approach.  The  inputs 
would  describe  the  functional  areas  for  application  development,  DoD  logistics 
system  goals,  and  objectives  for  individual  applications  or  standards.  The  plan 
would  also  show  the  relationships  between  specific  applications  and  system  goals, 
functional  areas,  and  development  costs.  It  would  provide  a  framework  for  priori¬ 
tizing  projects  and  allocating  resources  within  the  DLSS  program. 

The  second  option  would  include  descriptions  of  major  logistics  projects  being 
developed  by  DoD  Components  in  addition  to  the  DLSS  modernization  projects  being 
managed  by  DLSSO.  The  documentation  would  show  the  relationships  between  the 
projects  being  managed  by  other  DoD  Components  and  DoD  total  logistics  system 
goals,  functional  areas,  development  costs,  and  interface  requirements  with  DLSS 
projects.  These  inputs  would  provide  a  framework  for  prioritizing  DLSS  projects  in 
relationship  to  the  total  DoD  logistics  community.  While  this  second  approach  is 
clearly  better  from  a  planning  standpoint,  maintaining  information  on  the  many 
systems  being  developed  by  individual  DoD  Components  is  a  difficult  problem,  espe¬ 
cially  when  many  of  the  systems  are  in  the  early  development  stage. 

IRM  documentation  that  includes  modernization  plans  for  all  DoD  Components 
could  also  be  useful  in  defending  budget  requests  for  the  development  of  new 
systems.  The  IRM  documentation  would  illustrate  the  interrelationships  between 
DLSSO  projects  and  logistics  projects  being  developed  by  DoD  Components,  and 


would  show  the  relationships  between  logistics  modernization  projects  and  DoD 
goals.  The  IRM  documentation  would  provide  a  complete  statement  and  picture  of 
the  total  logistics  community  information  technology  and  modernization  projects 
and  requirements. 

A  senior  advisory  group,  composed  of  representatives  of  OSD,  DLSSO,  and 
selected  DoD  Components,  should  be  established  to  review  DLSS  modernization 
plans  and  logistics  system  IRM  plans  prepared  by  other  DoD  Components  to  ensure 
that  all  plans  include  the  requirements  necessary  to  ensure  effective  interfaces 
between  all  DoD  logistics  systems. 


CHAPTER  E.  SUMMARY  OF  PART  H  MODELS  REQUIREMENTS 


Part  II  has  presented  operational  requirements  and  considerations  for 
implementing  the  DLSS  functional  requirements  presented  in  Part  I.  The 
19  MODELS  requirements  presented  in  Part  II  are  summarized  in  this  chapter.  The 
section  title  for  the  requirement  is  listed  along  with  the  page  number  in  the  text  to 
facilitate  referral  to  the  rationale  for  the  requirement. 


A.  LOGISTICS  SYSTEMS  USER  REQUIREMENTS. 

A. 2  Inter-S/A  Interface  Requirements. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
the  capability  to  implement  on-line  user  interfaces  with  ICPs 
for  stock  availability  and  requisition  status  inquiry  for,  as  a 
minimum,  Priority  Group  I  materiel  requirements.  (Part  II, 
Chapter  A,  Section  A.2,  page  II-4) 


MODELS  Requirement:  The  MODELS  concept  must  provide  a 
broad  base  of  DoD  users  with  access  (not  necessarily  in  real 
time)  to  data  from  contracting  and  contract  administration 
activities  that  maintain  information  related  to  contract 
content  and  status.  (Correlates  to  MODELS  Requirement  — 
Part  I,  Chapter  C,  Section  C.2.a,  page  1-37.)  (Part  II, 
Chapter  A,  Section  A.2,  page  EI-4) 

A.3  Interface  Requirements  of  the  Defense  Transportation  Function. 

MODELS  Requirement:  DLSS  procedures  must  provide  for 
meeting  the  growing  need  for  inter-S/A  standardization  of 
information  to  be  collected  and  electronically  communicated 
between  DoD  transportation  agencies  and  customers  and, 
between  DoD  and  commercial  transportation  activities. 
(Correlates  to  MODELS  Requirement  —  Parti,  Chapter  E, 
page  1-81.)  (Part  II,  Chapter  A,  Section  A.3,  page  IT-6) 


ut  k.1  •-*  M  | 


A.4  Service-to-Service  Interface  Requirements. 


MODELS  Requirement:  Modernized  DLSS  procedures  and  the 
MODELS  information  exchange  technology  concepts  must 
provide  standardized  interfaces  to  unique  commodity  systems 
(e.g.,  ammunition,  petroleum).  Eventually  such  unique 
Service-to-Service  and  Service-to-DLA  procedures  and  auto¬ 
mated  systems  must  be  fully  integrated  into  the  MODELS 
concept.  (Part  II,  Chapter  A,  Section  A.4,  page  II-7) 


A.5  Joint  Chiefs  of  Staff  (JCS)  Mobilization  Interface  Requirements  to  the 
Logistics  System. 


MODELS  Requirement:  The  MODELS  concept  should  provide 
for  a  working  interface  between  joint  operations  systems  and 
the  DLSS.  (Correlates  to  MODELS  Requirement  —  Part  I, 
Chapter  E,  page  1-81.)  (Part  II,  Chapter  A,  Section  A.5, 
page  H-9) 


METHODS  OF  LOGISTICS  INFORMATION  EXCHANGE. 


B.l  Data  Standardization. 


MODELS  Requirement:  The  expanded-DLSS  procedures  must 
provide  for  the  identification,  definition,  control,  and  dissemi¬ 
nation  of  data  standards.  This  role  should  include  the  develop¬ 
ment  of  data  dictionaries.  (Correlates  to  MODELS  Require¬ 
ment  -  Parti,  Chapter  A,  Section  A.l,  page  I- 11.)  (Part  II, 
Chapter  B,  Section  B.l,  page  11-12) 


B.2  Variable- Length/Variable-Field  Transaction  Records. 


B.2.a  The  Variable-Length/V ariable-Field  Transaction  and  ANSI  X12  EBDI 
Standards. 


MODELS  Requirement:  DLSS  transaction  formats  should  be 
variable-length  records  and  should  conform  to  an  electronic 
data  exchange  standard.  Serious  consideration  should  be 
given  to  using  ANSI  X12  EBDI  Standards  to  establish 
compatibility  with  the  commercial  sector.  Therefore,  DLSS 
transaction  formats  should  be  formulated  and  established  in 
cooperation  with  the  Transportation  Data  Coordination  Com¬ 
mittee,  the  ANSI  X12  Committee  and  its  associated  subcom 
mittees,  and  industry  representatives.  (Part  II,  Chapter  B, 
Section  B.2. a,  page  11-19) 
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B.3  Interactive  Data  Access  and  Update. 
B.3.a  On-line,  Interactive  Access. 


MODELS  Requirement:  The  modernized  DLSS  must  estab- 
lish  procedures  and  standards  for  DoD-wide  interactive  logis¬ 
tics  information  inquiry.  (Part  II,  Chapter  B,  Section  B.3. a, 
page  H-22) 

B.3.b  Electronic  Mail  Access. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
lor  an  electronic  mail  capability.  (Part  II,  Chapter  B, 
Section  B.3.b,  page  13-24) 

B.3.c  Batch  Processing. 

MODELS  Requirement:  The  MODELS  concept  must  provide 
for  continued  use  of  batch  processing  and  the  standardized 
exchange  of  data  in  batches.  (Part  II,  Chapter  B,  Section  B.3.c, 
page  n-24) 

B.4  Heterogeneous  Data  Network  Interoperability. 

MODELS  Requirement:  DLSS  modernization  should  carefully 
review  existing  and  developing  communications  standards  for 
the  OSI  seven-layer  reference  model  to  facilitate  interoper 
ability  in  the  logistics  community. 

DLSSO  must  take  an  active  role  in  ensuring  adherence  to 
DoD-wide  logistics  applications  data  management  standards. 
The  MODELS  concept  should  be  developed  based  on  an 
assumption  that  the  appropriate  level  of  expertise  will  be 
available.  (Part  II,  Chapter  B,  Section  B.4.  page  II- 27 > 

B.5  Data  Base  Management. 

MODELS  Requirement:  The  MODELS  concept  recognizes  the 
use  of  modern  DBMS  technology  by  the  S  As  and  must  provide 
for  procedures  to  standardize  data  element  definitions  in  the 
S/As.  in  the  interim,  data  dictionaries  should  be  established  to 
facilitate  inter-S/A  data  element  translations.  'Correlates  to 
MODELS  Requirement  —  Part  I.  Chapter  A.  Section  A  1 
page  1-11  and  Part  II,  Chapter  B.  Section  B  1.  page  11  \2 
(Part  U,  Chapter  B,  Section  B.5,  page  113 1 > 

B.6  Distributed  Data  Base  Management 

MODELS  Requirement  The  MODELS  i-iincept  rn.io, 
structured  to  take  advantage  of  the  emerging  DDBMS 
nology.  Existing  DDBMS  technology  -h  uid  he  reveweo  \ 
determine  its  ability  to  address  the  needs  •*  *  he  >g:  -,ti 
community  ( Part  II.  Chapter  B.  Secti-  n  B  o  •_  ,u.  !I  U 


B.7  Data7Voice/Video  Communications. 


MODELS  Requirement:  The  MODELS  concept  must  be  struc¬ 
tured  to  accommodate  rapidly  evolving  advanced  computer 
and  communication  technologies.  (Part  II,  Chapter  B, 
Section  B.7,  page  11-36) 

LOGISTICS  MANAGEMENT  INFORMATION  REQUIREMENTS. 

C.l  Weapons  System  Management  Issues. 

MODELS  Requirement:  The  MODELS  concept  requires  a 
highly  efficient  and  reliable  system  of  telecommunications  and 
gateway  processors  to  support  inter-S/A  queries  and  transfer  of 
various  types  of  weapons  system-related  data.  Any  data 
exchange  programs  to  support  weapons  systems  must  be 
designed  to  accommodate  classified  data.  (Part  II,  Chapter  C, 
Section  C.l,  page  11-39) 

C.2  Priority  Issues. 

MODELS  Requirement:  The  MODELS  concept  should  provide 
for  modernized  DLSS  procedures  and  transaction  data  ele¬ 
ments  to  accommodate  implementation,  through  UMMIPS,  of 
separate  issue  and  transportation  priority  coding  systems. 

( Part  II,  Chapter  C,  Section  C.2,  page  13-40) 

C.3  In-transit  Visibility. 

MODELS  ReQuirement.  Modernized  DLSS  procedures  should 
improve  on  existing  supply-transportation  interfaces  by 
providing  specific  item  visibility  during  the  shipment  process. 
(Correlates  to  Models  Requirement  —  Part  I.  Chapter  E, 
Section  E  2.  page  1-88. 1  (Part  II,  Chapter  C,  Section  C.3, 
page  n  42  > 

C  4  Contract  Related  Information  Exchange. 

MODELS  Requirement  The  MODELS  concept  must  provide 
for  electronic  exchange  of  large  text-fields  of  contract-related 
information  ‘Correlates  to  MODELS  Requirement  —  Parti, 
Chapter  C.  Section  C  2  i.  page  1-37.)  (Part  II,  Chapter  C, 
Section  C  4,  page  II  42' 


INFORMATION  RESOURCES  MANAGEMENT  INI’IT 
CONSIDERATIONS. 


D.5  DoD  IRM  Program.  Goals. 


MODELS  Requirement:  Individual  S/A  logistics  ->ystems 
to  be  designed  with  the  total  DoD  logistics  community  m  no  no 
An  overall  DoD  logistics  systems  modernization  plan  should  o*- 
formally  prepared  and  regularly  updated  as  part  >f  tn** 
MODELS  continuing  modernization  process  Parr.  II 
Chapter  D,  Section  D.5,  page  13-44) 
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CHAPTER  A:  ANALYSIS  OF  SYSTEM  ARCHITECTURES 


A.  I  Introduction  and  Background. 

This  chapter  presents  a  review  of  the  organization  (architecture)  of  Depart 
ment  of  Defense  (DoD)-wide  logistics  systems.  It  includes  a  discussion  of  the 
capabilities  and  characteristics  of  the  existing  system  and  those  of  two  other 
alternatives  -  one  with  expanded  switching  nodes  and  one  using  gateway  processors 
(GPs).  These  architectures  are  summarized  in  the  following  paragraphs. 

The  existing  logistics  network  communications  system  architecture  consists  of 
two  Defense  Automatic  Addressing  System  (DAAS)  facilities  that  perform  the 
routing  and  interfacing  functions  required  to  achieve  interoperability  among  the 
various  logistics  systems.  Although  the  existing  architecture  can  satisfy  many  of  the 
required  functions  of  the  logistics  community,  it  is  vulnerable  to  equipment  failures. 
It  also  requires  an  expansion  of  the  centralized  data  bases  maintained  at  the  DAAS 
nodes  to  provide  the  desired  levels  of  on-line  inquiry,  as  discussed  in  Part  I  of  this 
report.  This  expanded  use  of  centralized  data  bases,  and  the  concept  of  retrans 
mitting  all  logistics  communications  through  central  sites  has  a  great  potential  for 
increasing  communications  costs.  It  is  also  difficult  to  maintain  large  centralized 
data  bases  that  must  be  updated  frequently  to  maintain  the  required  level  of  infor 
mation  accuracy  and  timeliness. 

The  first  alternative  reviewed  is  an  expansion  of  the  existing  configuration  to  a 
total  of  five  switching  nodes.  That  alternative  is  identified  because  of  the  reduced 
vulnerability  associated  with  multiple  switching  nodes.  However,  its  operational 
benefits  appear  to  be  limited  and  its  cost  would  be  substantially  higher. 

The  second  alternative  architecture  would  replace  the  switching  nodes  with 
interfacing  GPs  installed  at  most  major  logistics  sites.  These  GPs  would  perform 


many  of  the  functions  now  provided  by  DAAS.  Implementation  of  this  alternative 
would  offer  the  ability  to  access  local  data  bases  directly  using  a  decentralized  design 
concept.  Decentralization  of  data  bases  would  reduce  the  number  of  redundant  data 
bases  required  to  support  the  system  operation.  Phis  alternative,  designated 
Alternative  2,  offers  the  potential  of  reducing  the  system  wide  communications  cost. 

Chapter  B  discusses  telecommunications  issues,  including  anticipated  growth 
in  data  communications  traffic,  alternative  tariff  structures  for  the  Defense  Data 
Network  (DDN),  and  the  transition  of  the  specialized  logistics  networks  to  the  DDN 

Chapter  C  discusses  current  trends  toward  the  use  of  general  purpose  data  base 
management  systems  (DBMSs).  Those  trends  provide  improved  flexibility  and 
expanded  capabilities  for  logistics  systems.  However,  a  wide  variety  of  different 
DBMSs  have  been  selected  by  the  Services  and  the  Defense  Logistics  Agency  (  DLAi 
Variations  in  DBMS  characteristics  will  increase  the  need  for  data  element 
standardization  if  on-line  access  to  logistics  systems  data  bases  is  to  be  implemented 

The  current  interconnection  of  computer  and  communication  systems  in 
defense  logistics  exhibits  characteristics  of  both  centralized  and  distributed  designs. 
It  is  distributed  in  that  dispersed  logistics  organizations  operate  computer  facilities 
for  information  processing.  However,  it  exhibits  centralized  characteristics  through 
single  processing  installations  (e.g.,  DAAS)  designated  to  provide  control  over  the 
routing  of  logistics  documents  along  with  other  centralized  information  manage 
ment  functions. 

While  this  system  has  operated  effectively  for  more  than  20  years,  the  existing 
data  processing  communications  and  logistics  environments  are  rapidly  changing. 
For  example,  the  introduction  of  the  DDN  provides  the  capability  for  transmitting 
messages  using  a  variable-length  message  format.  That  format  permits  using 
flexible  interface  standards  responsive  to  the  individual  requirements  of  members  of 


the  logistics  community  iNote  Direct  remote  across  md  < t.mput*T  in  <  < *rti p i i t •  r  f: 
transfers  are  also  possible  through  l)I)N  > 

Further  environmental  changes  will  umir  with  the  i ntr<>*lu<  ten  .1  m.  *|.  r  n i  /■  o 
systems  being  developed  bv  the  Services  and  1)1  A  all  of  which  ro  ap.  i  it*  ’to 
capability  for  on  line  terminal  transactions  f'he  potential  a  <n  on*  n  in-.n',  r, 
processing  and  the  ant  hi  pa  ted  capabi  h  tv  to  exchange  graphic,  mt.muii  >n  •  a  •  •  t 
logistics  activities  will  n-sii  It  in  a  -.ignili*  ant  i  n<  r*-a  in  <la :  a  'iimuiii  it.  a; 
traffic. 

The  changing  environment  requires  that  the  Modernization  ,|  DFbn  • 
Logistics  Standard  Systems  <  MODKLSi  project  review  the  existing  DA  AS  >\  -t*  n, 
strui'ture  Another  reason  for  this  review  is  that  the  Defense  <  'ommunicit ,  n 
Agency  (DCA)  plans  to  impose  user  charges  tor  transmitting  data  over  the  l  > i ) \ 
That  charge  emphasizes  the  need  to  control  logistics  information  communication', 
costs  and  dictates  efficient  use  of  network  facilities 
A. 2  Existing  Communication  Network  System  Architecture 

System  architecture  is  defined  as.  ’’The  set  *t  design  principles,  including  the 
organization  of  functions  and  the  description  of  data  formats  and  procedures  used  tor 
the  implementation  of  a  user  application  network 

When  considered  in  terms  of  the  current  defense  logistics  system,  the  .-.vstem 
architecture  includes  the  data  processing  installations  of  the  Services.  1)1. A.  and 
General  Services  Administration  (GSA).  It  also  includes  the  Automatu  Digital 
Network  (AL'TODIN)  and  DDN  communications  networks  that  provide  the  primary 
media  for  logistics  data  communications  within  DoD  Such  special  purpose  logistics 
networks  as  the  Marine  Corps  Data  Network  (MCDN)  and  the  Defense  Logistics 
Agency  Telecommunications  Network  (DLANET)  must  also  be  considered  as 
components  of  the  existing  system  architecture. 
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A  1  i  Defense  Logistics  System  \r<  hitci  tun 

the  current .defense  logistics  system  posses.se-,  .  h.ir  .i.  ten, to  ■  ■  !  u.  if  »•  n » t  , , 

i/ed  and  distributed  irchiteetures  It  is  centralized  n  'hit  r  1 1  <  •  - 1  .  ,  k*  i  .  1 1  •  *r  m 

actions  ire  transmitted  through  entrai  sites  .1  DAAS  whrn  ttn  s  m  r>".  uw.-.f 
runted,  and  logged  Additional  eentrali/ed  processing  ><•<  urs  where  m<  >u<  u  1 1  hn  <lit  i 
bases  are  maintained  tur  storage  of  information  tur  a  single  Service  Agency  S  A  >r 
to  provide  a  common  svstem  wide  function  Kxainples  uf  these  data  bases  i  nciude  1  tie 
Army  s  Logistics  Intelligence  Kile  iLIK'  and  the  Federal  Catalog  Svstem  s  Defense 
Integrated  Data  System  (DII)si  maintained  bv  DLA's  Defense  Logistics  Services 
("enter  ( DLSC  >. 

Distributed  processing  occurs  throughout  the  logistics  system  Distribution  it 
processing  is  performed  on  a  functional  basis  [at  inventory  control  points  <I('Ps>, 
depots,  etc. I,  on  a  S/A  basis,  and  on  a  geographic  basis  at  numerous  locations 
throughout  the  world.  To  facilitate  the  analysis  of  system  architectures,  the 
following  general  categories  of  functional  processing  have  been  identified  . 

•  ICPs  —  These  sites  provide  the  item  management,  procurement,  and 
accounting  functions  associated  with  the  logistics  system. 

•  Depots  —  These  sites  provide  the  warehousing  and  storage  functions 
required  for  the  items  managed  by  the  ICPs.  In  some  cases,  a  depot  will 
support  a  single  ICP.  In  other  cases  multiple  depots  might  support  a  single 
ICP,  or  a  single  depot  might  serve  multiple  ICPs. 
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ir*1  responsible  for  th*1  redistribution.  transfer  donation  sale  a  rap  >r 
destru*  timi  >f  >'Xt  *‘s>  uni  oirplus  materiel  m»i  ***pji |imrn t 

•  I  rarisporlation  1*  a»  ilities  -  I'Iii’m1  ar*1  th*1  p**rt>  uni  u  rfie.ds  i  *<  a  a  t  ed 
with  th*1  movement  "t  m ;i t ** r i *• !  Thus*1  facilities  ar*1  primarily  r*1  ^pon  able 
fur  shipments  to  ami  from  tunes  *i<-pl.iv*ici  outside  th*1  <  'on  ti  nun  ta  i 
l  mted  States  i  ( '<  )\  l  S  * 

•  K**tail  Sit**s  A  broad  range  >t  retail  tail  lit  v  types  exists  within  the 
defense  supply  system  '  i ntermediate  and  unit  lev«»|i  Some  it  thes*1  sites 
have  responsibility  tor  inventory  management,  warehousing,  and  transpnr 
tation  that  parallel  activities  ol  th*1  wholi>sale  level 

•  Customer  Sites  -  Any  location  '  independent  of  size*  that  uses  materiel 
managed  by  the  wholesale  and  retail  levels  of  supply  is  a  customer  silt1. 
Customer  sites  include  maintenance  facilities,  military  bases,  national 
guard  installations.  Veterans  Administration  hospitals,  and  civilian 
agencies. 

•  Specialized  Services  -  A  number  of  specialized  services  are  operated  by 
DI- A  and  the  Services  to  support  the  defense  logistics  system.  Kxamples 
include  the  DLSC.  which  maintains  the  Catalog  System,  and  the  Defense 
Technical  Information  Center,  which  provides  for  storage  and  distribution 
of  scientific  and  technical  documents. 

A  simplified  version  of  the  existing  logistics  communication  system 
architecture  is  presented  in  Figure  A-l.  This  illustration  implies  the  existence  of 
direct  connections  between  the  two  central  DAAS  nodes  (at  the  Gentile  Air  Force 
Station  in  Dayton.  Ohio,  and  at  the  Western  Division  in  the  Defense  Depot  at  Tracy, 
California)  and  the  various  logistics  sites.  In  practice,  these  connections  are  made 
through  switched  data  networks  (either  AUTODIN  or  DDN)  that  provide  connec 
tivity  between  the  sites  and  DAAS. 


FIGURE  A- 1  EXISTING  SYSTEM  ARCHITECTURE 
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DAAS  is  responsible  for  performing  the  basic  functions  of  validation,  routing. 


editing,  and  maintaining  records  of  most  Defense  Logistics  Standard  Systems 
( DLSS)  related  communications  that  pass  between  originating  and  destination  sites. 


DAAS  performs  the  important  function  of  batching  different  types  of  documents 


addressed  to  a  particular  destination  in  a  single  message.  This  function  reduces  the 
impact  of  logistics  traffic  on  the  AUTODIN  and  communications  centers.  Communi 


cations  between  an  originating  site  assigned  to  one  DAAS  node  and  a  destination 


site  assigned  to  the  other  DAAS  node  do  not  pass  through  both  nodes  as  implied  by 


Figure  A  1. 


DAAS  performs  a  number  of  additional  special  functions  important  to  commu 


nications  and  processing  functions  of  the  logistics  system,  including: 


•  Maintenance  of  the  Department  of  Defense  Activity  Address  File 
(DoDAAF)  and  the  Military  Assistance  Program  Address  File  (MAPAF), 
which  contain  names,  addresses,  and  address  codes  of  activities  identified  in 
DLSS  transactions. 


* 


•  Part  number  to  National  Stock  Number  ( NSN)  and  NSN  validation  editing 
of  all  requisitions,  making  correcting  entries  when  possible. 

•  Operation  of  the  Defense  European  and  Pacific  Redistribution  Activity 
(DEPRA)  for  processing  excess  reports,  requisitions,  and  other  related 
supply  documents,  including  overseas  redistribution  functions.  This  func¬ 
tion  is  performed  at  the  Dayton,  Ohio  facility. 

•  Retention  of  Military  Standard  Billing  System  (MILSBILLS/  interfund 
billing  documents  on  file  for  120  days  to  accommodate  requests  for  retrans 
mission  at  the  Dayton,  Ohio  facility.  The  retention  period  is  currently  being 
increased  to  1  year. 

•  Operation  and  maintenance  of  the  Central  Data  Collection  Point  under 
DoD  4000.23  M,  Military  Supply  and  Transportation  Evaluation  Proce 
dures  (MILSTEP).  This  function  is  performed  at  the  Tracy,  California  facil 
ity. 

•  Maintenance  of  a  requisition  shipment  status  correlation  file  to  process 
Military  Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP)  mass 
cancellation  requests  and  Military  Transaction  Reporting  and  Accounting 
Procedures  (MILSTRAJP)  Materiel  Receipt  Acknowledgment  Documents 
(MRADs). 

•  Acting  as  destination  point  for  logistics  documents  during  periods  when 
MINIMIZE  conditions  are  imposed.  (MINIMIZE  conditions  occur  when 
military  operations  generate  a  high  level  of  communications  traffic.  To 
reduce  the  delays  experienced  by  high-priority  traffic,  all  other  trans 
missions  are  deferred  or  sent  using  alternative  means  such  as  the  U.S. 
mail.)  During  these  conditions,  DAAS  receives  all  requisitions  and 
forwards  them  in  accordance  with  the  requirements  of  MINIMIZE.  This 
may  include  the  use  of  mail  when  the  use  of  AUTODIN  is  prohibited.  DAAS 
may  also  be  asked  to  hold  all  routine  transmissions  and  send  only  priority 
transmissions,  unless  those  transmissions  have  the  Joint  Chiefs  of  Staff 
(JCS)  designator  in  the  event  of  mobilization. 

•  Termination  of  Foreign  Military  Sales  (FMS)  traffic  to  and  from  countries, 
based  on  changing  diplomatic  relationships. 

•  Response  to  requests  for  retransmission  of  documents  received  with  errors. 

•  Maintenance  for  30  days  of  an  input/output  message  tape  that  can  be  used 
for  tracing  specific  messages  and  documents. 

•  Provision  of  sources  of  supply  and  address  information  in  response  to 
interrogations  from  various  organizations. 


•  Responsibility  for  operation  and  interface  with  the  International  Logistics 
Communications  System  (ILCS).  DAAS  personnel  are  responsible  for 
configuring  the  on-site  ILCS  processing  equipment.  The  logistics  traffic 
originating  from  ILCS  sites  is  received,  processed,  and  routed  by  DAAS. 

•  Preparation  and  distribution  of  Logistics  Information  Data  Service  (LIDS) 
reports.  These  reports  are  extracts  from  the  maintained  history  records  of 
documents  processed  by  DAAS. 

•  Provision  of  special  functions  for  the  Services.  Examples  of  these  functions 
include: 

-  Transmitting  duplicate  data  for  storage  in  the  Army’s  LIF  maintained  at 
Presidio  of  San  Francisco,  California. 

-  Submitting  Materiel  Obligation  Validation  (MOV)  responses  for  organi 
zations  unable  to  prepare  their  own. 

-  Preparing  punched  cards  of  transaction  responses  for  Navy  ships. 

-  Modifying  transactions  in  accordance  with  specific  operating  requests  of 
the  individual  S/As.  These  modifications  are  usually  performed  in 
response  to  a  request  from  a  S/A  that  cannot  accommodate  a  modifica¬ 
tion  made  to  the  DLSS. 


•  Acting  as  interface  between  civilian  agencies  and  the  defense  logistics 
system.  Approximately  10  percent  of  current  DAAS  traffic  originates  from 
civilian  agencies.  The  major  civilian  agency  users  of  DAAS  are  the  GSA, 
U.S.  Department  of  Agriculture,  State  Department,  National  Security 
Agency,  Central  Intelligence  Agency,  Federal  Bureau  of  Investigation, 
General  Accounting  Office,  Coast  Guard,  National  Aeronautics  and  Space 
Administration  (NASA),  and  the  Federal  Aviation  Administration  (FAA). 


•  Preparation  of  special  reports  as  requested  by  organizations  such  as  the 
Inspector  General,  General  Accounting  Office,  and  DLA. 


•  Maintenance  of  MILSTRIP  Supplement  1  Routing  Identifier  and  Distribu¬ 
tion  codes. 


From  a  communications  perspective,  DAAS  performs  gateway  and  switching 
functions  required  to  ensure  interoperability  among  the  various  installations  of  the 
defense  logistics  system.  In  addition,  DAAS  accumulates  copies  of  documents  and 
system  performance  statistics  required  for  effective  system  management. 
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Of  equal  importance  to  understanding  the  operation  of  the  current  defense 
logistics  system  architecture  are  the  exceptions  to  the  configuration  just  described. 
As  shown  in  Figure  A  1,  some  logistics  installations  are  collocated.  In  such  cases, 
direct  communications  between  collocated  sites  may  occur,  eliminating  the  need  for 
using  a  long  communications  path  in  which  a  message  originates  at  a  site,  travels  to 
DAAS,  and  then  returns  to  the  same  site.  An  example  of  this  direct  communications 
is  the  Defense  Construction  Supply  Center  (DCSC)  in  Columbus.  Ohio.  At  that 
installation,  the  ICP  communicates  directly  with  the  depot,  bypassing  DAAS 
However,  copies  of  transactions  between  the  DCSC  ICP  and  the  DCSC  depot  are 
transmitted  to  DAAS  for  archiving  and  maintenance  of  performance  records. 

A  second  example  of  intrafacility  traffic  is  the  interchange  of  data  between  the 
numerous  logistics  facilities  that  exist  at  the  Norfolk  Naval  Base.  Virginia.  The 
activities  housed  on  that  base  do  not  follow  a  consistent  policy  regarding 
transmission  of  logistics  traffic  through  DAAS.  The  Naval  Supply  Center  (NSC)  at 
Norfolk,  Virginia  transmits  all  information  through  DAAS,  even  though  the 
destination  of  those  transmissions  might  also  be  in  Norfolk,  Virginia.  This 
procedure  is  used  to  take  advantage  of  the  routing,  error  checking,  and  delivery 
capabilities  of  DAAS.  However,  the  Naval  Air  Rework  Facility  (NARF)  communi¬ 
cates  with  the  NSC  using  locally  leased  lines  and  bypassing  DAAS.  While  it  is  not 
unusual  for  intra-Service  customers  to  communicate  directly  with  their  Service 
ICPs,  the  result  is  that  information  produced  in  DAAS  LIDS  reports  of  data  commu 
nications  activity  does  not  represent  the  entire  defense  logistics  communications 
loading.  The  absence  of  these  data  precludes  an  accurate  assessment  of  the  overall 
performance  of  the  logistics  system. 

Most  Military  Standard  Contract  Administration  Procedures  (MILSCAP) 
traffic  bypasses  DAAS  going  directly  from  the  source,  usually  a  DCASR,  to  the 
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the  shipment  status  information  be  provided  to  the  requisitioner  Thes*  exceptions 
must  be  eliminated  to  the  maximum  extent  possible  by  the  MODELS  design  concept 
A.3  Architectural  Alternatives. 

In  view  of  S/A  modernization  programs,  needed  changes  to  DLSS  procedures 
and  transaction  formats,  implementation  of  DDN,  and  communications  technology 
advances,  the  existing  logistics  system  architecture  must  be  reviewed  to  determine 


nq  '.hat  review  is  the 


1  :  t'  f 


:  tnose  twu 


.  >  .  "it  Phu-e  a  of  the 


:  i rut  i  mparison 


\>  •  - ’  •  ••  a  ;  >  >-r  must 


tne  na>is  T  the 


r  it.  r.  <:  exist*  n; 


i  r  ?r 

:>  \>  ,n  tne  short 


■  ;  . .  rertvnts  -f  the 


••  o ^  t.itips  m  DLSS 

•  ••  it  it;  Of  -mm a  implemented 

•  •>  \  :  r  no  facilities.  This 

’  ii  .  1 . t .»• '  .  a n  oe  updated  at 
>  :  •  i : .  a  •  H  avever.  the  arc  hi 
A-...-  *no  -native  is  awaiting 


T  •  \  -v  *U*  \  l  \ 


••  •  •:  •>  .  <t  ■'  •  A.tr  tne  i  -a  r  rent  directions  of  new  S  A 

i  ••••■•••.  •  a  •  :  c;  .  ncreased  .evei  >f  an  line  inquiry, 

s.r.*:  •  n  >f  ’  ::>■->  »tu:  is  r-  asin^  .eveis  ot  automation.  It 
it  O'.-  r  t  r  i  u  -uv;  t  *.  n  q  i  rut  re.  •  vi  nq  graphics  data. 


'  ■ie  o,  stern  »r  n.  vet  m  .>t  o  mm  it.ite  ul  logistics  functions  —  supply. 
:r  msp.  rtat.  n  f  ::.m.  ■  1;  must  r>e  mpatibie  with  logistics  activities 

triat  ire  n,>t  n- >\%  w.tn.n  the  mmaifiate  purview  ot  the  DLSS  —  food,  cloth 


■  nq.  -tc 


l  he  fVstem  must  be  designed  t*  support  planning  and  operations  needs  of 
[)<>!)  under  noth  wartime  and  peacetime  conditions. 


|AD-Ai»*  7M 

DEFENSE  LOGISTICS  STANDARD  SVSTEAS  FUNCTIONAL 
REQUIREMENTS^)  LOGISTICS  MANAGEMENT  INST  KTHESDA  HD 

P  A  VOUNQ  MAR  87  LMI-DL5Q2R1  NDAM3-QS-C-Q129 

2/2 

UNCLASSIFIED 

F/G  13/3 

NL 

Using  those  criteria  the  following  two  alternative  architectures  were 
developed: 


•  Multiple  switching  nodes,  to  function  in  a  manner  similar  to  DAAS,  but 
located  at  several  additional  sites. 

•  GPs  at  major  logistics  installations  to  serve  the  unique  interface  require¬ 
ments  of  the  installation  at  which  they  are  located. 

Both  these  alternative  architectures  are  based  on  the  assumption  that  a  central 
organization  is  assigned  the  responsibility  for  development  of  software  updates  and 
the  management  of  the  node  configurations  and/or  the  gateway  installations.  The 
communication  network  architectures  of  these  two  alternatives  are  shown  in 
Figure  A-2  and  are  described  in  detail  in  the  following  subsections  along  with 
general  observations  of  their  advantages  and  disadvantages. 

A.3.a  Alternative  1  —  Multiple  Switching  Nodes. 

Alternative  1  operates  in  a  similar  manner  to  that  of  the  existing  system.  The 
difference  is  that  the  two  DAAS  sites  are  augmented  by  additional  DLSS  nodes. 
Each  node  provides  the  basic  functions  of  routing,  error  checking,  document  storage, 
and  report  processing  performed  by  the  existing  DAAS  sites. 

To  simplify  configuration  management  of  the  overall  system,  all  nodes  are 
functionally  identical.  However,  special  responsibilities  are  assigned  individual 
nodes  (for  example,  DEPRA)  for  reporting  of  overall  logistics  system  performance 
measures  via  M3LSTEP. 

Each  node  serves  a  specific  geographic  region  and  is  designed  to  back-up  other 
nodes.  The  geographic  assignment  of  logistics  sites  to  a  specific  node  minimizes 
transmission  distances  between  sites.  Vulnerability  is  reduced  by  providing  back-up 
capability.  The  DLSS  nodes  are  installed  at  existing  logistics  installations  to 
minimize  the  costs  of  acquiring  new  facilities  to  house  equipment  and  personnel. 
DDN  facilities  are  used  to  provide  internode  communications  required  for 


FIGURE  A-2.  ALTERNATIVE  ARCHITECTURES 
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transmission  of  data  base  updates,  back-ups,  and  exchange  of  administrative 
information. 

The  architecture  of  this  alternative  is  similar  to  that  of  the  public  telephone 
system,  in  which  each  central  office  serves  the  subscribers  in  a  geographical  area  in 
a  star  configuration,  while  all  central  offices  can  communicate  directly  with  each 
other.  This  alternative  provides  advantages  similar  to  those  of  the  public  telephone 
system.  It  offers  a  potentially  high  level  of  system  reliability  and  reduced 
vulnerability  because  the  nodes  can  back  up  each  other.  It  also  offers  the  potential  to 
reduce  total  transmission  distance  because  of  the  proximity  of  the  nodes  to  the 
customers  served. 

A  possible  disadvantage  of  this  alternative  is  the  administrative  complexity  of 
maintaining  identical  configurations  at  multiple  installations.  Effective  configu¬ 
ration  management  of  these  nodes  requires  the  use  of  strict  controls,  carefully 
administered  by  a  central  site.  A  second  disadvantage  is  an  increase  in  computer 
facility  costs  that  is  directly  related  to  the  number  of  nodes  implemented. 

A.3.b  Alternative  2  —  Gateways. 

Alternative  2  is  implemented  using  GPs  at  wholesale  logistics  activities  (ICPs, 
depots),  DCASR  offices,  transportation  facilities,  and  major  intermediate  retail-level 
activities.  The  GPs  ensure  that  all  interfacility  traffic  entering  the  DDN  is 
formatted  using  a  single  standard  consistent  with  the  transaction  format  require¬ 
ments  of  the  DLSS. 

The  GP  replaces  many  functions  currently  performed  by  DAAS  including 
routing,  formatting,  specialized  interface  processing,  file  maintenance,  and  accumu¬ 
lation  of  traffic  statistics.  Collocated  facilities  are  served  by  a  single  GP.  Similarly, 
customer  sites  too  small  for  installation  of  a  GP  at  their  own  facility  access  the 
logistics  network  through  the  nearest  GP. 
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In  this  alternative,  communications  between  two  logistics  facilities  is  per¬ 
formed  in  the  manner  indicated  in  Figure  A-3.  The  message  begins  at  a  terminal  in 
the  originating  facility.  The  terminal  communicates  with  the  host  computer  system 
of  the  organization  to  which  the  terminal  is  assigned.  If  the  host  computer  system 
requires  additional  information  to  respond  to  the  terminal  inquiry,  it  transmits  a 
request  for  information  to  the  GP  which  performs  the  following  functions: 

•  Translation  (if  necessary)  from  the  inquiry  language  of  the  host  to  the 
common  DLSS  inquiry  language. 

•  Routing  of  the  inquiry  through  DDN  to  the  correct  destination. 

•  Transmitting  additional  inquiries  to  other  destinations  if  the  first  desti¬ 
nation  does  not  have  the  required  information. 

GPs  are  implemented  in  a  manner  that  permits  software  updates  and  data  base 
interrogation  from  remote  locations.  This  feature  of  the  design  enables  a  central 
design/programming  organization  to  manage  the  configuration  of  all  gateways.  It 
also  permits  centralized  acquisition  of  data  collected  by  each  GP. 

Alternative  2  does  not  represent  merely  breaking  DAAS  into  small  systems 
and  installing  it  at  individual  logistics  sites.  The  two  significant  differences  that 
exist  between  this  alternative  and  the  DAAS  architecture  are  as  follows: 

•  The  GPs  of  Alternative  2  are  not  identical  but  are  tailored  to  the  require¬ 
ments  of  the  S/A  site  at  which  each  is  installed.  When  a  GP  serves  multiple 
S/A  sites,  it  includes  appropriate  modules  for  each  S/A  supported.  This 
concept  reduces  the  complexity  and  equipment  costs  of  the  GPs. 

•  The  outgoing  and  incoming  transactions  are  translated  (if  necessary)  into 
the  language  of  the  S/A-site  host  computer. 

As  indicated  in  Figure  A-3,  the  GPs  directly  interconnect  host  computer  facili 
ties  with  each  other.  All  communications  between  GPs  is  in  a  common,  standard 
DLSS  format.  Also,  as  indicated  in  Figure  A-3,  the  GPs  support  nearby  logistics 
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FIGURE  A-3.  TYPICAL  COMMUNICATIONS  BETWEEN  LOGISTICS  FACILITIES  -  ALTERNATIVE  2 


installations  that  may  communicate  with  the  GP  using  leased  lines,  dial-up 
facilities,  or  DDN. 

The  GPs  could  also  support  direct  terminal  connections.  While  that  capability 
may  be  desirable  because  it  bypasses  major  host  installations,  it  could  have  a 
significant  impact  on  the  size  and  complexity  of  the  GP.  This  possibility  will  be 
examined  during  Phase  3  of  the  MODELS  project. 

The  concept  shown  in  Figure  A-3  is  similar  to  the  manner  in  which  DDN 
operates.  GPs  administered  by  the  Defense  Logistics  Standard  Systems  Office 
(DLSSO)  and  managed  by  a  centralized  organization  such  as  the  Defense  Automatic 
Addressing  System  Office  (DAASO)  would  be  installed  at  a  logistics  site  to  provide 
the  interface  between  the  local  logistics  processor  and  other  logistics  installations  in 
the  same  manner  as  the  centrally  managed  DDN  processors  provide  interfaces 
between  the  data  processing  facility  and  the  communications  network. 

The  procedures  used  by  retail  customers  to  access  the  GPs  and  other  elements 
of  the  wholesale  system  would  be  the  same  as  those  currently  in  use  for  retail-level 
access  to  the  wholesale  system.  Intra-S/A  communications  would  be  unaffected  by 
this  alternative  and  would  not  require  a  GP  for  intra-S/A  retail/wholesale  communi¬ 
cation. 

All  communications  traffic  is  transmitted  directly  from  origin  to  destination 
without  the  need  for  routing  through  an  intermediate  destination. 

The  GPs  do  not  provide  the  on-line  centralized  data  base  management  func 
tions  provided  by  the  existing  system  and  Alternative  1.  Instead  they  provide  access 
to  the  distributed  data  bases  located  at  the  installations  at  which  data  originate. 
This  design  represents  a  significant  departure  from  concepts  that  are  currently  used. 
On-line  response  times  to  inquiries  for  this  alternative  will  be  a  function  of  response 
times  of  the  host  computers  whose  data  bases  are  being  interrogated.  Thus,  it  will  he 


important  to  include  an  electronic  mail  capability,  so  responses  can  be  deposited  in 
the  mail  box  of  the  terminal  initiating  an  inquiry. 

Alternative  2  appears  to  offer  a  number  of  advantages  over  both  the  existing 
DAAS  system  and  Alternative  1.  The  architecture  offered  by  this  alternative 
guarantees  that  the  GPs  will  capture  all  traffic  entering  or  leaving  the  logistics 
installation.  As  a  result,  the  quality  of  performance  data  recorded  by  these  devices 
will  be  significantly  improved  over  that  available  from  the  other  two  architectures. 

It  is  anticipated  that  six  types  of  nodes  would  be  implemented;  one  for  each  of 
the  Services,  one  for  DLA,  and  one  for  civilian  agencies.  This  level  of  flexibility 
permits  accommodation  of  the  unique  change  schedules  and  capabilities  of  indi¬ 
vidual  S/As.  It  also  provides  a  method  for  assessing  the  cost  of  S/A-unique  modifica¬ 
tions  to  the  S/A  requesting  them. 

Alternative  2  also  minimizes  communications  costs  by  permitting  direct 
communications  from  origin  to  destination.  It  eliminates  the  processing  delays  and 
costs  associated  with  the  routing  of  all  communications  through  an  intermediate 
point. 

A  final  advantage  is  that  the  Alternative  2  approach  minimizes  system 
vulnerability  since  failure  of  an  individual  GP  would  only  disable  the  logistics 
facility  to  which  it  is  connected. 

Some  disadvantages  are  also  associated  with  this  approach.  The  complexity  of 
numerous  GPs  installed  throughout  the  world  might  result  in  significant  admin¬ 
istrative  difficulties.  Since  configurations  will  not  be  identical,  it  may  be  difficult 
and  time-consuming  to  provide  the  configuration  management  required  to 
accommodate  data  base  updates  and  ongoing  software  enhancements. 

All  of  the  advantages  and  disadvantages  along  with  economic  considerations 
will  be  analyzed  and  evaluated  in  greater  detail  during  Phase  3  of  the  MODELS 
project. 


CHAPTER  B:  TELECOMMUNICATIONS  ISSUES  AND  DATA  BASE 
MANAGEMENT  SYSTEM  CONSIDERATIONS 


B.l  Telecommunications  Issues. 

The  ability  of  the  defense  logistics  community  to  operate  effectively  in  a 
changing  technological  environment  depends  on  the  quality  of  service  provided  by 
the  data  communications  system.  Existing  communications  services  are  provided 
from  a  number  of  sources  including: 

•  The  AUTODIN  system  that  provides  message-switched  data  transmission 
services  worldwide  for  DoD.  AUTODIN  is  used  as  the  primary  data  commu¬ 
nications  service  for  transmission  of  logistics  documents. 

•  Dedicated  communications  networks  for  on-line  inquiries  into  logistics 
data  bases  include  the  DLANET  and  MCDN.  The  transmission  facilities  for 
both  these  networks  are  American  Telephone  and  Telegraph  ( AT&T)-leased 
Dataphone  II  service  providing  9,600  bits  per  second  (bps)  digital 
communications  service  using  dedicated  lines.  The  terminal  devices  used  to 
access  this  AT&T  service  are  International  Business  Machines  Corporation 
(IBM)  3270  terminals  or  their  equivalent.  Data  switching  and  interfacing 
with  IBM-compatible  host  computers  is  provided  by  NCR  Comten 
processors.  These  processors  provide  message  switching  capabilities. 

•  Voice  dial-up  services,  including  the  AT&T  direct  dial  network  and  the 
Automatic  Voice  Network  (AUTOVON),  are  used  to  access  facilities,  using 
low-speed  terminals  equipped  with  modems.  These  services  are  primarily 
used  for  on-line  inquiry  and  low  volume  transactions,  such  as  communi¬ 
cations  between  individual  users  and  retail  facilities. 

•  Dedicated  leased  lines  are  used  to  provide  data  transmission  between 
facilities  located  on  the  same  base  or  within  the  same  city.  Communications 
over  leased  lines  is  performed  at  low-speed  using  modems. 

•  The  DDN,  currently  under  development,  will  provide  the  DoD  with  the  next 
generation  of  data  communications  services.  DDN  will  replace  some 
communications  services  currently  in  use.  The  first  operational  applications 
of  the  DDN  facilities  for  transmission  of  logistics  data  will  be  for  communi¬ 
cations  between  the  two  DAAS  sites  and  for  a  limited  number  of  Navy 
installations,  at  which  Stock  Point  Logistics  Integrated  Communications 
Environment  (SPLICE)  equipment  is  now  installed.  Most  major  users. 


including  MCDN  and  DLANET,  are  planning  to  use  DDN  in  place  of  their 
existing  transmission  network  facilities. 


The  transition  to  DDN  offers  the  opportunity  to  introduce  expanded  flexibility 
and  increased  capabilities  over  that  currently  existing.  However,  use  of  DDN 
requires  a  thorough  understanding  of  its  limitations  and  unique  operating  concepts 
to  ensure  that  requirements  of  the  defense  logistics  community  are  satisfied.  This 
section  discusses  issues  associated  with  the  transition  from  use  of  the  existing 
system  to  the  DDN. 

B.2  Traffic  Growth. 

During  the  next  10  years,  logistics  data  communications  traffic  is  expected  to 
increase  significantly.  The  increases  will  result  from  normal  growth  in  logistics 
traffic,  improved  on-line  access  to  automatic  data  processing  ( ADP)  equipment,  new 
requirements  for  data  transmission  between  facilities  (for  example,  exchange  of 
information  between  transportation  facilities),  removal  of  the  existing  80-byte  (card 
column)  limitation  on  transaction  document  size,  and  the  transmission  of  graphics 
data.  While  it  is  difficult  to  determine  the  impact  of  each  factor  precisely,  it  is 
important  to  develop  planning  estimates  to  avoid  the  potential  problem  of  degraded 
service  because  of  communications  capacity  limitations.  These  estimates  are 
particularly  important  because  current  logistics  traffic  is  approximately  one-third  of 
all  defense  AUTODIN  data  traffic. 

The  manner  in  which  these  traffic  growth  forecasts  have  been  developed  is 
discussed  in  the  following  paragraphs. 

B.2. a  On-Line  Processing. 

The  existing  procedure  of  providing  requisition  and  shipment  status  using 
batch  processing  procedures  is  assumed  to  continue  even  after  on-line  capabilities 
are  provided.  These  batch-processing  procedures  are  implemented  through  retail- 
level  ADP  systems  interrogating  ICPs  about  the  status  of  all  active  requisitions  at 


I 

I 

I 

I 

i 

time  intervals  specified  by  the  Uniform  Materiel  Movement  and  Issue  Priority  j 

System  (UMMIPS).  The  assumption  of  continued  automated  (batch)  interrogation  j 

of  logistics  files  is  based  on  the  facts  that  batch  systems  currently  incorporate  this 
capability  and  that  Services  will  be  unwilling  to  operate  without  it.  Data  acquired 
from  batch  transfers  is  designated  "pushed  data." 

On-line  inquiries  about  requisition  status,  item  availability,  and  catalog  data 
will  represent  an  additional  source  of  data  traffic.  These  inquiries  are  needed  to 
acquire  information  not  available  at  the  retail  level.  For  that  reason,  on-line  traffic 
will  be  added  to  the  existing  batch  traffic  rather  than  replacing  it.  On-line  traffic 
has  been  assumed  to  equal  2.23  times1  the  existing  batch  traffic  for  follow-ups, 
supply  and  shipment  status  requests,  and  DAAS  interrogations.  Data  resulting  I 

from  on-line  inquiries  is  designated  "pulled  data.” 

B.2.b  New  Requirements. 

Major  unsatisfied  requirements  are  yet  to  be  defined  for  the  data  communi  ! 

cations  required  to  improve  the  capability  for  monitoring  shipment  status  of 
materiel  from  origin  to  destination  and  to  improve  the  ability  of  DTS  facilities  to 
plan,  schedule,  and  control  shipments.  The  specific  changes  anticipated  are  the  use  ^ 

of  an  electronic  GBL  that  would  have  applications  for  most  CONUS  shipments  and 
the  increased  use  of  DDN  for  the  transmission  of  ATCMD  or  similar  data  for 
shipments  outside  the  Continental  United  States  (OCONUS).  Thus,  it  can  be 
assumed  that  additional  electronic  transactions  will  be  transmitted  for  most 


'The  factor  2.23  was  derived  from  the  data  presented  in  Solicitation  Document  -  Acquisition 
of  Computer  Systems  and  Support  Services  for  the  Stock  Point  /ADP  Replacement  f  SPAR )  Project, 
Department  of  the  Navy,  Automatic  Data  Processing  Support  Office  (ADPSO)  Project  No  84-25, 
Attachment  9,  Washington  Navy  Yard,  Washington,  D  C. 


shipments.  These  additional  transaction  transmissions  will  occur  each  time  a 
shipment  is  processed  by  a  node  of  the  transportation  system. 


Assuming  that  on  the  average,  10  requisitions  are  consolidated  into  a  single 
shipment  unit,  and  that  two  (or  more  for  OCONUS  shipments)  transportation 
transactions  (data  records  or  documents)  are  generated  for  each  shipment  unit,  the 
total  number  of  additional  transactions  will  equal  20  percent  of  the  number  of 
requisitions.  This  assumption  is  used  to  forecast  traffic  growth  related  to 
transportation  transactions. 

Additional  traffic  growth  is  likely  to  occur  through  the  increased  use  of 
MILSCAP  documentation  related  to  contract  activities.  However,  the  current  level 
of  this  traffic  is  so  low  relative  to  other  logistics  traffic  that  it  can  be  assumed  to  have 
a  negligible  affect  on  total  traffic  load. 

B.2.c  Variable-Length  Messages. 

The  replacement  of  the  fixed  80-column  format  with  a  variable-length  format 
offers  the  potential  for  reducing  the  total  amount  of  data  that  is  transmitted.  This 
reduction  would  result  from  not  needing  to  provide  multiple  copies  of  the  same  data 
field  when  more  than  one  80-column  card  image  is  required  for  a  document.  These 
multiple  copies  are  now  necessary  to  permit  identification  of  continuation  cards  in 
the  event  that  the  card-set  becomes  separated. 

However,  experience  shows  that  the  increased  flexibility  associated  with 
variable- length  formats  leads  to  an  increase  in  total  data,  which  results  from  the  fact 
that  information  now  not  included  in  existing  fixed  formats  is  included  in  the 
variable-length,  more  flexible  format.  In  addition,  the  variable  format  offers 
flexibility  for  including  textual  comments,  resulting  in  still  more  data  being 
transmitted.  Finally,  in  some  variable  formats,  information  required  for  message 
destinations  to  identify  blank  fields  (such  as  a  series  of  field  delimiters  containing 
special  characters)  leads  to  additional  data  transmission. 


For  these  reasons,  a  20  percent  increase  in  current  average  document  length  is 
forecast.  While  this  estimate  does  not  affect  the  number  of  documents  transmitted, 
it  changes  the  average  document  length  from  80  to  96  bytes  per  document. 


B.2.d  Graphics  Data  Transmission. 

Plans  are  underway  for  transmission  of  graphics  data  to  supplement  logistics 
text  and  data  currently  being  transmitted.  While  estimates  of  the  number  of  bytes  to 
be  transmitted  for  a  single  graphic  are  readily  developed,  the  applications  of  these 
data  are  not  fully  defined.  Since  the  amount  of  data  associated  with  a  single  graphic 
can  be  extremely  large,  depending  on  the  size  of  the  graphic  and  the  desired 
resolution,  the  transmission  of  graphics  will  probably  be  restricted  to  a  limited 
number  of  documei  '  types. 

Graphics  data  will  probably  be  used  under  the  following  conditions: 

•  Some  procurement  transactions  will  be  accompanied  by  a  graphical 
description  of  the  materiel  to  be  procured.  This  description  will  be  used  to 
assist  the  negotiator  in  the  determination  of  a  reasonable  price  for  the 
contract.  It  is  likely  that  such  graphics  data  would  be  acquired  from  a  new 
data  base  to  be  added  to  the  existing  catalog  data.  Therefore,  the  retrieval 
of  catalog  data  would,  on  occasion,  be  accompanied  by  the  retrieval  of 
graphics  data. 

•  A  modernized  MILSCAP  encompassing  procurement  functions  would 
include  transmission  of  graphics  information  associated  with  solicitations 
when  that  information  was  available. 

•  Supply  system  customers  who  desire  verification  that  the  item  being 
ordered  meets  their  technical  requirements  might,  on  occasion,  require  the 
transmission  of  supplementary  graphics  data  during  retrieval  of  catalog 
information. 

Using  these  conditions,  it  is  likely  that  use  of  graphics  data  would  gradually 
increase  as  it  is  added  to  the  DIDS  Federal  Supply  Catalog  data  base.  Since  the 
schedule  of  these  types  of  improvements  is  uncertain  and  the  applications  of  graphics 
data  have  not  been  identified,  they  are  not  used  in  the  traffic  analysis  model 
associated  with  this  report. 


However,  an  estimate  of  the  magnitude  of  the  impact  of  graphics  data  can  be 
made  assuming  that  such  data  are  added  to  20  percent  of  all  modernized  MILSCAP 
solicitation  documents  and  10  percent  of  requests  to  the  DIDS  data  base  for  catalog 
information  and,  that  the  average  graphics  transmission  requires  50,000  bytes. 
Under  these  assumptions,  the  total  logistics  traffic  will  increase  by  4  percent,  or  an 
estimated  annual  increase  of  more  than  200  million  bytes  in  traffic,  as  a  result  of  the 
use  of  graphics  data  during  the  next  5  years. 

Traffic  at  specific  locations  will  increase  by  an  even  greater  amount.  For 
example,  DLSC  in  Battle  Creek,  Michigan,  which  currently  responds  to  the  majority 
of  catalog  data  requests,  will  be  significantly  affected  by  the  transmission  of  graphics 
data.  Thus,  it  is  important  that  the  future  graphics  data  transmission  requirement 
be  considered  during  planning  and  design  of  communications  facilities  at  DLSC, 
Battle  Creek,  Michigan. 

B.2.e  Total  Traffic  Growth. 

The  impacts  of  each  source  of  traffic  growth  (on-line  inquiries,  new  require¬ 
ments,  variable-length  records,  and  graphics  data)  are  summarized  in  Table  B-l.  In 
addition  to  this  increase,  communications  requirements  can  be  expected  to  increase 
at  a  compounded  rate  of  approximately  5  percent  per  year.  This  rate  of  growth  has 
been  experienced  for  the  past  5  years  and  is  anticipated  to  continue  in  the  future. 
Table  B-l  shows  that  normal  growth  and  the  changing  logistics  environment  will 
increase  the  level  of  logistics  traffic  by  a  factor  of  approximately  3. 

These  capacities  are  based  on  peacetime  logistics  traffic.  Significant  additional 
capacity  must  be  available  to  allow  for  the  increase  in  traffic  that  would  occur  during 
wartime  conditions.  The  AUTODIN  has  an  operational  condition  known  as 
MINIMIZE,  which  requires  that  all  nonessential  traffic  be  removed  from  the 
network  during  periods  of  national  emergencies.  In  the  past,  logistics  traffic  has 
been  considered  nonessential,  with  the  result  that  most  supply  system  traffic  is 


TABLE  B-1.  ESTIMATED  INCREASES  IN  LOGISTICS  TRAFFIC 
OVER  EXISTING  TRAFFIC 

(57.3  million  documents  equal  to  4.58  billion  bytes  of  data) 


LOGISTICS  SYSTEM  TRAFFIC 
INCREASES  DUE  TO: 

10-YEAR  INCREASE  IN  TRAFFIC 

Billions  of 
Monthly  Bytes 

Percent 

Increase 

Normal  Growth 

2.89 

63 

On-Line  Capabilities 

1.93 

42 

Graphics  Data 

0.18 

4 

New  Requirements  (Transport 
and  Contracts  Documents) 

0.05 

1 

Variable-Length  Records 

0.92 

20a 

Combined  Impact  of  All  Increases 

13.37b 

2  92b 

*  Variable-length  records  will  not  change  the  number  of  documents  but  are  assumed  to 
increase  the  average  document  length  (number  of  bytes)  by  20  percent 

b  Percentage  and  total  represent  compounded  growth  of  each  increase  factor  on  base 


removed  from  the  network  during  MINIMIZE  conditions.  To  provide  effective 
support  for  military  operations  with  reduced  levels  of  supply  (inventory  in  motion), 
this  situation  must  be  corrected. 

Increased  reliance  on  automation  requires  that  future  communications  system 
designs  be  adequate  to  accommodate  logistics  requirements  during  wartime  condi¬ 
tions.  It  is  likely  that  in  the  future,  the  defense  logistics  system  will  be  unable  to 
operate  without  continued  access  to  data  communications  services. 

On  the  basis  of  this  analysis,  close  coordination  must  be  maintained  between 
the  representatives  of  the  defense  logistics  community  and  DCA.  This  coordination 
is  essential  to  provide  the  adequate  communications  capacities  needed  to  ensure  the 
availability  of  logistics  support  services  under  all  conditions. 


B.3  Communications  Charges. 

At  the  present  time,  the  Services  and  DLA  are  contributing  funds  to  DCA  for 
the  implementation  of  the  DDN.  That  funding  is  based  on  a  fixed  assessment 
developed  during  the  early  phases  of  the  system’s  implementation. 

However,  a  tariff  structure  will  be  established  for  DDN  in  which  "subscribers 
will  be  billed  based  upon  their  actual  use  of  the  network’s  facilities.  It  is  anticipated 
that  costs  will  be  less  than  those  of  public  data  networks  providing  similar  services, 
and  much  less  than  those  of  dedicated  facilities.  Billing  algorithms  that  implement 
cost-by-use  tariff  structures  are  normally  sensitive  to  such  parameters  as  time  of 
day,  message  size,  and  traffic  type. ”2  The  same  document  indicates  that  "Project 
managers  who  optimize  billing  parameters  in  a  manner  consistent  with  mission 
objectives  will  effectively  reduce  their  data  communication  costs.” 

Because  of  the  volume  of  data  communications  traffic  transmitted  by  the 
logistics  community,  the  costs  of  overall  system  operation  will  be  sensitive  to  the 
manner  in  which  the  tariff  structure  is  defined  and  the  architecture  of  the  data 
communications  system. 

B.3.a  Tariff  Structure. 

Although  the  DDN  tariff  structure  has  not  yet  been  established,  it  is  likely  to 
include  similar  components  used  for  the  tariff  structures  of  commercial  systems 
including: 

•  Access  to  Service  —  Some  commercial  value-added  networks  offering 
packet-switched  services  include  the  cost  of  the  communications  line 
between  the  customer’s  facility  and  the  nearest  switch  or  concentrator  with 
the  monthly  lease  cost  of  the  port.  In  other  cases,  acquisition  of  this  access 


2 Transitioning  to  the  Defense  Data  Network:  A  Management  Checklist,  Prepared  for  the 
Office  of  the  Assistant  Secretary  of  Defense  (Manpower,  Installations,  and  Logistics), 
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is  the  customer’s  responsibility.  In  still  other  cases,  the  access  is  provided 
by  the  supplier  of  value-added  services  but  is  billed  as  a  separate  monthly 
charge.  It  would  be  beneficial  to  logistics  users  if  the  DDN  rate  structure 
included  the  local  access  arrangements.  This  factor  is  particularly  impor¬ 
tant  for  military  bases  at  which  logistics  facilities  are  collocated  with  other 
military  units.  A  DDN-provided  access  service  would  minimize  the  possi- 
bility  of  duplicate  access  facilities  being  leased  by  the  various  facility 
tenants. 

•  Port  Charges  —  These  charges  are  incurred  monthly.  In  most  cases,  they 
include  the  cost  of  the  port  and  any  interface  equipment  such  as  pad  ~*t 
assemblers/disassemblers  (PADs)  and  modems  required  to  access  the 
service.  In  most  cases,  these  charges  vary  with  the  communications  data 
rate.  However,  it  is  significant  to  note  that  the  charges  do  not  vary  linearly 
(i.e.,  doubling  the  data  rate  does  not  double  the  monthly  charge;.  When  the 
rate  structure  for  DDN  is  established,  the  DCA  must  determine  the 
relationship  between  port  charges  and  data  rate.  Since  most  wholesale 
level  logistics  facilities  transmit  and  receive  large  volumes  of  data,  it  would 
be  beneficial  to  the  logistics  community  if  this  nonlinear  relationship  were 
maintained. 

•  Usage  Charges  —  Usage  charges  are  incurred  in  proportion  to  the  amount 
of  data  transmitted.  These  charges  are  calculated  on  the  basis  of  the 
number  of  kilopackets  (1,000  packets  of  approximately  128  bytes  of  data) 
transmitted.  A  comparison  of  the  costs  of  the  various  commercial  services 
(shown  in  Table  B-2)  indicates  that  each  service  tends  to  allocate  costs 
between  port  charges  and  usage  charges  in  a  different  way.  For  example, 
AT&T  charges  more  for  ports  and  less  for  usage  than  Tymnet.  In  this 
example,  high-volume  users  benefit  from  the  AT&T  charges.  Again,  it 
would  be  beneficial  to  the  logistics  supply  community  if  DCA  developed  a 
tariff  structure  that  was  favorable  to  high-volume  users. 

It  is  evident  from  this  discussion  that  close  coordination  should  be  maintained 
between  representatives  of  the  defense  logistics  community  and  DCA.  However, 
equally  important  is  the  design  of  a  communications  network  system  architecture 
that  recognizes  the  advantages  to  be  gained  from  efficient  use  of  the  communications 
system. 
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TABLE  B-2.  COMPARISON  OF  RATE  STRUCTURES 


RATE  ITEM 

AT&T 

ACCUNET 

GTE 

TELENET 

MCDONNELL/ 

DOUGLAS 

TYMNET 

Access  to  Service 

Customer  Provided3 

Dedicated  Access  Included 
in  Port  Charges 

$1,200  for  9.6  kilo¬ 
bytes  per  second 
(kbps)  Access 

Port  Charges  for 

9.6  kbps  Access 

$61 5/mo. 

Si, 525/mo. 

$535/mo 

Usage  Charges  in 
S/kilopacketb 

$0.67 

$1.19 

$1  28 

a  Customer  options  for  service  access  include  either  voice  lines  or  data  lines  if  data  lines  are  desired.  AT&T  OATAPHONE 
Digital  Service  would  be  acquired  Typical  monthly  costs  for  this  service  would  be  SI  75  plus  $  60  per  mile  for  9  6  kbps  service 
b  A  kilopacket  equals  1 .000  packets  A  majority  of  services  use  1 28  bytes  as  the  average  packet  size 


B.3.b  MODELS  Consideration. 

An  important  consideration  in  the  development  of  the  MODELS  network 
architecture  is  the  influence  of  the  DAAS  operation  on  communications  costs.  The 
transmissions  from  the  transaction-originating  source  to  DAAS  and  from  DAAS  to 
the  transaction’s  destination  effectively  double  the  total  amount  of  data  that  are 
communicated.  In  addition,  the  interconnection  of  the  DAAS  facilities  with  DDN 
will  result  in  the  need  for  additional  ports  and  access  lines,  a  factor  that  will  further 
increase  communications  costs.  However,  as  noted  in  the  Chapter  A  discussion  of 
system  architectures,  total  system  costs  (including  both  communications  costs  and 
processing  costs)  must  be  considered  when  considering  alternatives  to  the  existing 
architecture. 

B.4  Logistics  Data  Networks. 

A  number  of  data  communications  networks  are  operational  or  under  develop¬ 
ment  for  on-line  access  to  logistics  data  bases.  They  include  DLANET  and  MCDN, 
operated  by  DLA  and  the  Marine  Corps,  respectively. 


Both  DLANET  and  MCDN  provide  a  combination  of  transmission  and 
switching  services  that  will  be  replaced  by  DDN.  As  a  result,  their  role  is  likely  to 
change  significantly,  from  providing  communications  network  services  to  providing 
front-end  processing  services  required  for  access  to  the  host  computers  of  their 
organizations.  Organizationally,  therefore,  the  technical  capabilities  they  offer 
should  include  a  greater  emphasis  on  computer  and  Local  Area  Network  (LAN) 
capabilities,  and  a  reduced  emphasis  on  long-distance  communications  and  network 
monitoring. 

The  technological  issues  associated  with  the  anticipated  DLANET  and  MCDN 
responsibilities  will  be  similar  to  those  currently  being  addressed  by  the  Air  Force’s 
Logistics  Network  (LOGNET)  program.  That  program  includes  (1)  implementation 
of  intersite  gateways  with  DDN  and  AUTODIN,  (2)  installation  of  LANs  to  interface 
host  computers  at  the  Air  Force  Logistics  Command  (AFLC)  and  the  Air  Logistics 
Centers  (ALCs),  and  (3)  development  of  intelligent  gateway  processors  (IGPs).  These 
components  will  be  integrated  into  networks  providing  single  points  of  access  to  all 
data  bases  and  intersite  communications  facilities  of  the  Air  Force  logistics 
community.  The  IGPs  will  enable  personnel  to  communicate  with  a  number  of 
different  logistics  systems  using  a  single  command-and-inquiry  language. 

This  discussion  of  the  LOGNET  program  is  not  intended  to  advocate  the 
approach  being  used  by  the  AFLC  but  rather  to  provide  an  example  of  the  types  of 
communications  services  that  must  be  made  available  at  local  installations  to 
accommodate  the  growth  in  data  traffic  resulting  from  changes  being  made  to  the 
defense  logistics  system.  It  is  important  that  the  S/A  identify  the  changes  required 
at  their  host  facilities  so  that  those  facilities  can  provide  the  levels  of  service 
required  by  the  enhancements  to  the  logistics  system  discussed  in  this  report. 


CHAPTER  C:  DATA  BASE  MANAGEMENT 

C.l  Background. 

In  1981,  the  Federal  Government  had  more  than  15,000  installed  computers, 
approximately  50  percent  of  which  were  less  than  5  years  old.  The  National  Bureau 
of  Standards  (NBS)  estimates  that  a  majority  of  those  Federal  computers  could 
support  a  DBMS.  Notwithstanding  that  potential,  only  about  3,700  DBMSs  were  in 
use  in  the  Federal  Government  in  1981.  By  1986  at  least  28  percent  of  the  computers 
will  have  installed  some  type  of  DBMS.  By  1990,  the  Federal  Government  is  pro¬ 
jected  to  have  more  than  40,000  computers.  Of  those  Federal  computers  acquired  in 
the  1985  —  1990  timeframe,  most  will  install  some  type  of  file  or  data-management 
capability.  These  projections  imply  that  by  1990,  the  Federal  Government  could 
have  more  than  30,000  Data  Management  Systems  (DMSs)  and  DBMSs,  roughly  a 
10-fold  increase  over  the  1980/1981  estimate. 

A  significant  number  of  logistics  systems  in  every  Service  and  in  the  DLA  are 
utilizing  DBMS  technology.  The  MODELS  system  design  concept  is  certain  to 
include  DBMS  technology  to  facilitate  the  flexibility  needed  in  the  next  generation 
of  the  DLSS,  both  to  accommodate  logistics  operational  changes  and  to  incorporate 
the  variable-length  record/variable-field  record  discussed  in  Part  II,  Chapter  D. 

Given  the  potential  that  over  30,000  data-management  related  packages  will 
be  selected  and  implemented  in  Federal  data-processing  facilities  by  1990,  respon 
sible  information  managers  will  need  assistance  in  making  cost  effective  selection 
decisions.  Even  if  these  data-management  facilities  are  "included”  in  a  system 
acquisition,  the  decision  to  use  one  capability  versus  another  can  have  enormous 
cost/benefit  implications. 
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This  chapter  provides  an  introduction  to  the  extent  of  DBMS  use  already 
ongoing  in  the  DoD  and  discusses  development  efforts  for  interfacing  heterogeneous 
distributed  data  base  management  systems  (DDBMSs),  a  vital  factor  in  realizing  the 
full  potential  of  modernized  logistics  management  systems  in  the  S/ A. 

C.2  Data-Management  Approach. 

A  great  number  of  data-management  approaches  exist,  ranging  from  tradi¬ 
tional  application  systems  (usually  programmed  in  COBOL)  to  DBMSs  (integrated 
systems,  that  permit  sharing  of  available  data,  shared  data  resources  utilizing  data 
dictionaries,  query  languages,  report  writers,  telecommunications  software,  and 
other  features).  The  various  commercial  packages  or  groupings  of  packages  can  be 
categorized  under  three  major  data-management  approaches: 

•  Traditional  application  systems 

•  DBMSs 

•  DMSs. 

These  three  approaches  are  representative  of  the  three  major  strategies  now  being 
used  for  data  management. 

This  discussion  concentrates  on  DBMSs  and  their  use  in  the  DoD  community. 
The  central  design  activities  for  each  of  the  Services  and  DLA  were  contacted  for  a 
list  of  the  DBMSs  used  in  major  DoD  logistics  systems.  Other  organizations  were 
contacted  as  well  since  a  large  number  of  organizations  in  the  Services  procure 
hardware  and  software  independently.  A  discussion  is  also  presented  of  the 
heterogeneous  DDBMS  efforts  underway  in  the  Services. 

Standardization  efforts,  both  commercial  and  Federal,  for  various  DBMS- 
related  activities  are  discussed  in  Appendix  D.  NBS  is  playing  a  major  role  in  this 
area,  working  closely  with  various  American  National  Standards  Institute  (ANSI) 
groups. 
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This  discussion  of  DBMS  applications  demonstrates  the  current  emphasis 
within  the  logistics  community  on  the  use  of  generalized  packages.  It  also  demon¬ 
strates  an  increasing  level  of  research  and  development  (R&D)  into  the  development 
of  DDBMSs  capable  of  accessing  heterogeneous  data  bases  at  dispersed  locations. 

Although  these  trends  are  encouraging  in  that  they  demonstrate  the  applica¬ 
tion  of  modern  software  technology  to  the  problems  of  logistics  data  management, 
they  are  also  alarming  because  of  the  diversity  of  software  packages  being  used. 
This  diversity  further  highlights  the  importance  of  the  DLSS  if  interoperability 
between  systems  is  to  be  maintained. 

C.3  DBMSs  Used  by  the  Services  and  DLA. 

Table  C-l  provides  a  list  of  DBMSs  currently  in  use  or  planned  for  logistics 
applications  by  each  Service  and  DLA.  Primarily,  commercial  DBMS  packages  are 
listed  here.  The  trend  in  all  the  Services  and  DLA  is  away  from  the  tendency  to 
develop  home-grown  DBMSs  or  file  management  systems,  toward  commercially 
available  DBMSs.  The  use  of  off-the-shelf  products  helps  to  ensure  that  software  can 
be  maintained  in  a  cost-effective  manner  and  increases  the  ability  to  accommodate 
system  upgrades. 

An  Army  study  group  is  currently  evaluating  DBMSs  for  use  in  mainframe 
environments.  Nomad  II  is  a  user-oriented  relational  DBMS  used  today  on  IBM 
equipment  for  information-retrieval  applications.  The  Army  is  looking  for  a  rela¬ 
tional  DBMS  to  be  used  in  its  production  environment.  The  Army  is  also  sponsoring 
the  development  of  a  prototype  common  data  language  for  retrieving  data  from 
heterogeneous  DBMSs. 

The  Naval  Supply  Systems  Command  (NAVSUP)  is  currently  funding  a  major 
system  modernization  effort  in  which  the  UNIVAC494  computers  are  being 
replaced  with  IBM  3080  computers  using  Tandem  computers  as  front-end  processors 
(FEPs).  DBMSs  are  a  critical  component  of  the  NAVSUP  effort.  A  study  is 
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TABLE  C-1 .  DATA  8ASE  MANAGEMENT  SYSTEMS  IN  THE  DoD  COMMUNITY 


Marine  Corps 


Datacom  DB 

DMR 

Informix 

Mistress 

Nomad  II 

System  2000 

TOTAL 


Encompass 
FOCUS 
IOMS 
IDS  II 

Model  204 

System  2000 

TAPS 

TIS 

TIS 

TOTAL 

TOTAL 


ADABAS 

CONDOR 

Datacom  DB 

dBase  II 

DGDBMS 

DM-4 

QMS  1100 

ENFORM 

FOCUS 

IDMS 

IDS 

IMS 

IMS 

IMS 

INGRES 
INGRES 
Mapper 
Model  204 
system  2000 
TOTAL 


ADABAS 

FOCUS 


ADABAS 
dBase  II  &  III 
dBase  II  &III 
DMS  II 
DMS  1100 
Encompass 
IMS 

Model  204 

SEED 

TIS 

TOTAL 
TOTAL 
TOTAL 
Unified  DB 


HARDWARE 


IBM 

IBM 

Unix-based  minis 
Unix-based  minis 
IBM 
IBM 

Perkm-Elmer 


Tandem 

IBM 

IBM 

Honeywell 

IBM 

IBM 

Perkm-Elmer 

Perkm-Elmer 

IBM 

Perkm-Elmer 

IBM 


IBM  3083 
Zenith  100s 
NAS  3000/5000 
Zenith  100s 
Data  General 
Honeywell  DPS  8 
Sperry 
Tandem  16 
IBM  4341 

Magnuson  M80/43 

Honeywell  DPS  8 

Amdahl  V8 

IBM  4341 

IBM  3083 

PDP  H/70 

VAX  11/780 

Sperry 

IBM  4341 

Cyber  1 70 

DEC  PDP  11/70 


Zenith 

Burroughs 

Sperry 

Tandem 

IBM 

IBM 

IBM 

IBM 

VAX 

IBM 

Perkin-Elmer 

Gould 
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underway  to  examine  a  representative  sampling  of  DBMSs  that  subscribe  to  the 
Conference  on  Data  Systems  Language  (CODASYL)  data  model  concept  to  deter 
mine  the  most  portable  subset  of  facilities  within  the  CODASYL  data  model.  Since 
the  Navy  has  procured  the  IDMS  DBMS,  a  subscriber  to  the  CODASYL  data  model 
concept,  a  specific  subset  of  IDMS  has  been  recommended  for  use  by  the  Navy  to 
maximize  portability.  A  further  discussion  of  this  effort  is  presented  in  Appendix  D. 

Marine  Corps  operations  are  currently  supported  on  IBM  mainframe^,  IBM 
personal  computers  (PCs),  and  Amdahl  equipment.  ADABAS  is  the  DBMS  used  in 
the  mainframe  environment,  while  FOCUS  is  used  on  the  PCs. 

C.4  Heterogeneous  DDBMS  Management  Efforts. 


Four  prototype  developments  for  interfacing  heterogeneous  DDBMS  are  cur¬ 
rently  underway  in  DoD. 

The  Army  has  contracted  with  Computer  Corporation  of  America  (CCA)  to 
adapt  its  MULTIBASE  system  to  act  as  a  front-end  software  package  for  two  data 
bases:  System  2000  DBMS  and  the  Data  Manager  Routine  (developed  by  the  Army). 
The  MULTIBASE  software  will  run  on  a  separate  FEP. 

A  second  contract,  funded  by  AFLC,  involves  the  development  of  a  prototype 
MULTIBASE  front-end  for  the  integrated  design  support  system,  which  will  provide 
design,  manufacturing,  and  engineering  data  for  the  development  of  weapons 
systems.  This  system  is  being  developed  by  CCA  as  a  subcontractor  to  Rockwell 
International,  the  prime  contractor  for  the  B-l  bomber  development.  Interfaces 
must  be  provided  for  the  AFLC  and  the  many  other  second-  and  third-tier 
subcontractors  involved  in  the  B-l  program.  Users  will  include  the  Air  Force, 
aerospace  contractors,  and  subcontractors.  The  data  bases  will  contain  proprietary 
information. 

The  Integrated  Manufacturing  Distributed  Database  Administration  System  is 
a  prototype  software  system  that  provides  update  and  retrieval  services  over 
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preexisting,  distributed,  heterogeneous  files  and  data  bases.  The  project  is  being 
sponsored  as  part  of  the  NBS  Advanced  Manufacturing  Research  Facility  and  is 
being  conducted  by  NBS  in  Gaithersburg,  Maryland,  along  with  the  University  of 
Florida.  The  Advanced  Manufacturing  Research  Facility  at  NBS  is  being  con 
structed  as  a  testbed  for  research  in  the  automation  of  small  batch  manu-facturing 
systems,  in  particular  for  systems  producing  machined  parts  in  lots  of  1,000  or  less. 
Construction  started  in  late  1981,  and  by  late  1986,  the  testbed  will  be  made 
available  for  selected  research  by  academic  and  industrial  organizations,  research 
institutions,  and  Government  agencies.  The  project  is  funded  by  NBS  and  the  Navy 
Manufacturing  Technology  Program  and  is  significantly  supported  by  industry 
through  donations  or  loans  of  major  components  and  through  cooperative  research 
programs. 

The  Integrated  Information  Support  System  is  a  software  system  being  devel¬ 
oped  by  the  Air  Force.  It  achieves  control  of  and  access  to  information  in  preexisting, 
distributed,  heterogeneous  data  bases  to  allow  data  shareability  and  to  provide  a 
means  for  improving  data  quality  and  data  timeliness.  Engineering,  manufactur 
ing,  and  business  applications  will  be  supported.  Integrated  Information  Support 
System  research  is  being  conducted  by  Boeing,  D.  Appleton  Company,  the 
Structured  Dynamics  Research  Corporation,  and  Control  Data  Corporation  under 
contract  with  the  U.S.  Air  Force  at  Wright-Patterson  Air  Force  Base  in  Dayton, 
Ohio. 

Research  efforts  are  under  way  at  the  Laboratory  of  Database  Systems 
Research,  Naval  Postgraduate  School  in  Monterey,  California,  for  the  development 
of  a  Multi-Lingual  Database  System.  This  approach  enables  the  user  to  access  and 
manage  a  large  collection  of  data  bases  via  several  data  models  and  their  corre 
sponding  data  languages  without  the  restriction  of  a  single  data  model  and  a  specific 
data  language.  A  specification  has  been  presented  for  the  implementation  of  an 


interface  that  translates  Structured  Query  Language  (SQL)  calls  into  attribute- 
based  data  language  requests.  The  design  goals  involve  developing  a  system  that  is 
accessible  via  a  relational/SQL  interface,  a  hierarchical  Data  Language  I  interface,  a 
network/CODASYL  interface,  and  an  entity-relationship/Daplex  interface.  Addi¬ 
tional  details  describing  those  activities  are  presented  in  Appendix  D. 
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D:  DATA  BASE  MANAGEMENT 


E:  GLOSSARY 


APPENDIX  A:  OPEN  SYSTEMS  INTERCONNECTION  MODEL 


In  1977,  the  International  Standards  Organization  (ISO)  established  a  sub¬ 
committee  to  develop  an  architecture  for  defining  processing  functions  performed  in 
a  data  communications  system.  This  subcommittee  produced  a  model  known  as  the 
Open  Systems  Interconnection  (OSI)  model  that  serves  as  a  framework  for  defining 
standards  for  linking  heterogeneous  computers.  The  OSI  model  uses  a  structuring 
technique  known  as  layering. 

In  this  model,  communications  functions  are  divided  into  a  hierarchical  set  of 
layers.  Each  layer  performs  a  related  subset  of  functions  required  to  communicate 
with  another  system,  and  each  layer  relies  on  the  next  lower  layer  to  perform  more 
primitive  functions.  For  the  communications  system  to  operate,  the  same  set  of 
layered  functions  must  exist  in  the  two  communicating  systems. 

The  peer  (corresponding)  layers  in  the  two  different  systems  communicate 
using  a  set  of  rules  or  conventions  known  as  protocols.  A  protocol  is  defined  by 
syntax,  semantics,  and  timing.  Syntax  includes  data  format  and  signal  levels; 
semantics  are  the  control  information  for  coordination  and  error  handling;  timing 
includes  speed  and  sequencing.  A  graphical  description  of  the  OSI  model  is 
presented  in  Figure  A-l.  The  dashed  lines  in  that  figure  represent  the  layers  that 
must  be  compatible  with  each  other  for  successful  system  operation.  The  solid  line 
indicates  the  layers  that  are  physically  interconnected  with  each  other. 


7.  APPLICATION 
LAYER 


6.  PRESENTATION 
LAYER 


5.  SESSION 
LAYER 


4.  TRANSPORT 
LAYER 


3.  NETWORK 
LAYER 


2.  DATA-LINK 
LAYER 


1.  PHYSICAL 
LAYER 


The  OSI  model  has  seven  layers: 

•  Layer  1  —  Physical  Layer.  This  layer  is  responsible  for  the  transmission  of 
an  unstructured  bit  stream  using  a  physical  link.  It  defines  the  mechanical, 
electrical,  and  procedural  characteristics  required  to  establish,  activate, 
and  maintain  a  link. 

•  Layer 2  —  Data-Link  Layer.  This  layer  controls  the  flow  of  information 
between  devices.  It  groups  bits  into  frames,  controls  the  data  transmission 
rates,  adds  the  header  and  trailer  (control  bits)  into  frames,  and  holds  the 
data  for  transmission  until  the  receiving  device  is  ready  to  accept  it.  The 
Data  Link  Layer  also  defines  the  manner  in  which  errors  occurring  at  the 
Physical  Layer  will  be  detected  and  corrected. 

•  Layer  3  —  Network  Layer.  This  layer  defines  the  manner  in  which  packets 
of  data  are  transmitted  through  a  network.  A  message  may  be  made  up  of 
more  than  one  packet.  The  routes  followed  by  the  packets  may  be  indepen¬ 
dent  (datagram)  or  all  the  packets  in  a  message  may  follow  the  same  route 
(virtual  circuit).  The  Network  Layer  defines  the  routing,  addressing,  and 
congestion  control  associated  with  these  transmission  paths. 

•  Layer  4  —  Transport  Layer.  This  layer  defines  the  error-recovery 
procedures  that  will  be  used  and  provides  end-to-end  flow  control.  Flow 
control  is  used  to  ensure  that  the  transmitting  device  is  not  sending  more 
data  than  can  be  accepted  by  the  receiving  device. 

•  Layer  5  —  Session  Layer.  This  layer  defines  the  manner  in  which  connec¬ 
tions  (sessions)  between  devices  are  established,  managed,  and  terminated. 
It  also  defines  checkpoints  and  restart  services  in  the  event  that  communi¬ 
cations  are  interrupted. 

•  Layer  6  —  Presentation  Layer.  This  layer  defines  the  interface  between  the 
communications  system  and  the  applications  programs.  The  Presentation 
Layer  also  defines  processing  activities  that  may  serve  a  common  require¬ 
ment  of  both  the  communications  and  applications  programs  such  as 
encryption,  text  compression,  and  reformatting. 

•  Layer  7  —  Applications  Layer.  This  layer  includes  the  user  software  such  as 
data  base  management  programs  or  accounting  software. 

It  is  not  necessary  to  define  all  seven  layers  for  every  communications  system. 
For  example,  a  system  that  is  made  up  of  two  processors  that  are  directly  connected 
with  each  other  does  not  require  the  definition  of  the  Network  Layer.  Alternatively, 
some  systems  include  the  use  of  multiple  processors  and  interfaces  to  perform  the 
overall  communications  task.  In  those  cases,  different  layers  must  be  defined  at 
various  points  in  the  communications  system. 


Figure  A-2  demonstrates  the  use  of  the  OSI  model  to  represent  the  case  of  a 
system  that  uses  front-end  processors  (FEPs).  Figure  A-3  is  an  example  of  a  system 
that  uses  an  interface  controller  to  access  a  communications  system  such  as  a  Local 
Area  Network  (LAN).  From  these  examples,  one  can  see  that  the  use  of  interface 
equipment  such  as  the  FEP  or  the  interface  controller  can  provide  the  ability  to 
modify  the  design  of  the  processor  (host)  containing  the  applications  programs 
without  requiring  redesign  of  the  communications  system,  since  design  changes  in 
the  host  processor  are  accommodated  through  the  modification  of  the  interface 
device.  In  some  cases,  current  modernization  activities  of  the  Services  are  making 
use  of  FEPs  in  this  manner.  The  Intelligent  Gateway  Processor  (IGP)  that  will  be 
used  by  the  Air  Force  Logistics  Command  (AFLC)  is  an  example  of  such  a  device. 
FEPs  offer  a  potential  capability  for  rapidly  modifying  a  system  in  response  to 
changing  interface  or  processing  requirements  that  occur  in  the  defense  logistics 
information  communications  systems. 
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FIGURE  A-2.  OPEN  SYSTEMS  INTERCONNECTION  MODEL  FOR  FRONT-END  PROCESSOR 
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FIGURE  A-3.  OPEN  SYSTEMS  INTERCONNECTION  LIKE  MODEL  FOR  A  LOCAL  AREA  NETWORK 
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APPENDIX  B: 


INFORMATION  RESOURCES  MANAGEMENT  PLAN  OUTLINE 


This  outline  describes  the  basic  structure  of  an  Information  Resources  Manage¬ 
ment  (IRM)  input  document  that  might  be  developed  for  the  logistics  community 
encompassed  by  the  Defense  Logistics  Standard  Systems  (DLSS)  functional 
requirements  shown  in  Part  I,  Chapter  A,  Figure  A-l  of  this  report.  This  outline 
generally  follows  the  examples  provided  in  the  Strategic  Information  Resources 
Management  Planning  Handbook  prepared  by  the  General  Services  Administration 
(GSA).  However,  the  outline  is  modified  to  incorporate  additional  information 
planning  techniques  to  accommodate  the  Department  of  Defense  (DoD)  Planning, 
Programming,  and  Budgeting  System  (PPBS).  The  outline  contains  sections  that 
cover  the  Current- Year,  Budget- Year,  and  Five-Year  Plan  and  that  do  not  appear  as 
major  headings  in  the  GSA  IRM  plan  outline. 

1.  SUMMARY  Contains  a  Foreword  and  Executive 

Summary. 

2.  PLANNING  ENVIRONMENT  Describes  the  purpose  and  scope  of  IRM 

planning  inputs  that  can  influence  logis¬ 
tics  information  resources  planning. 

2.1  INTRODUCTION  Describes  the  purpose,  scope,  planning 

philosophy,  and  definitions;  states  the 
importance  of  IRM  planning  in  prioritiz¬ 
ing  projects  and  supporting  budget 
requests;  emphasizes  the  need  for  top 
down  planning  and  the  involvement  of 
top  management  in  the  process. 

2.2  CURRENT  ENVIRONMENT  Describes  the  current  information  sys 

terns  being  used  in  the  logistics  commu 
nity  in  terms  of  hardware,  applications, 
and  resource  requirements. 
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2.3  ENTERPRISE  MODEL 


2.4  SUBJECT  AREA  DATA  BASES 


2.5  INFORMATION  FLOW 
ANALYSIS 


2.6  TECHNOLOGY  ASSESSMENT 


2.7  IRM  PLANNING  FRAMEWORK 


Describes  the  logistics  system  in  terms 
of  specific  functions;  breaks  down,  or 
decomposes  major  functions  into  sub¬ 
functions;  decomposes  functions  to  the 
level  of  repetitive  processes  depending 
on  the  level  of  planning  detail  desired; 
presents  the  functional  breakdown  in  a 
diagrammatic  form  to  eliminate  vol 
umes  of  text  and  make  it  easier  to  under¬ 
stand  relationships  between  functions; 
uses  the  model  to  develop  a  joint, 
common  understanding  of  the  functions 
covered  in  the  IRM  input;  also  serves  as 
a  means  for  dividing  the  analysis  process 
into  logical  subdivisions  that  can  be 
assigned  to  independent  development 
projects. 

Describes  in  broad  terms  the  subject 
area  data  bases  (e.g.,  stock  inventory) 
that  are  applicable  to  the  functions 
included  in  the  IRM  documentation; 
maps  subject  area  data  bases  back  to  the 
functional  areas  they  support  (e.g., 
wholesale  inventory  management). 

Diagrammatically  represents  the  infor 
mation  required  and  information 
produced  by  the  lowest-level  functions 
described  in  the  Enterprise  Model  (this 
helps  planners  define  data  base  struc 
tures  and  decide  where  data  inter¬ 
changes  are  required  between  functions 
or  organizations). 

Summarizes  the  technology  that  will  be 
available  over  the  5-year  planning  hori¬ 
zon  of  the  IRM  plan;  covers  such  areas  as 
security,  hardware,  software,  data  base 
systems,  and  communications;  evaluates 
the  changes  in  technology  in  terms  of 
price  and  capability;  assesses  the  impact 
of  technological  changes. 

Describes  the  organizational  structure 
for  IRM  planning  and  provides  schedules 
and  planning  check  lists. 


2.8  PERFORMANCE  EVALUATION 
PROCEDURES  AND  CRITERIA 


3.  ASSESSMENT  OF  PRIOR- 
YEAR  PLAN 
PERFORMANCE 


3.1  EVALUATION  OF  IRM 
PROCESS 


3.2  ADJUSTMENTS  NEEDED  FOR 
THE  CURRENT  YEAR 


3.3  PLANNING  OPTIONS  FOR  THE 
BUDGET  YEAR 


3.4  PRIORITIES  FOR  THE 
BUDGET- YEAR  PLAN 


4.  CURRENT-YEAR  IRM  PLAN 


4.1  GOALS  AND  OBJECTIVES 


4.2  INFORMATION  PROJECTS 


Describes  the  criteria  by  which  the 
performance  of  projects  will  be  evaluated 
and  specifies  the  procedures  to  be  used  in 
performing  the  evaluation. 

Provides  an  evaluation  of  the  prior 
year’s  performance  measured  against 
the  previous  Current-Year  Plan  and 
describes  adjustments  that  need  to  be 
made  to  the  Previous- Year  Plan  to 
create  a  new  Current-  Year  Plan. 

Gives  an  assessment  of  the  IRM  process 
and  how  well  it  performed  in  terms  of 
project  management  and  resource  con¬ 
trol. 

Describes  adjustments  needed  in  the 
prior  Budget- Year  Plan  to  convert  it  to 
the  Current-Year  Plan;  reviews  goals, 
objectives,  project  priority,  and  resource 
requirements. 

Defines  options  by  possible  scenarios 
described  in  terms  of  technological  possi¬ 
bilities,  likely  functional/  organizational 
requirements,  and  resource  constraints. 

Describes  how  resources  should  be  allo¬ 
cated  to  competing  projects;  makes  the 
priorities  sufficiently  specific  to  allow 
subordinate  organizations  to  make 
resource  allocations  without  subjecting 
the  decisions  to  further  study. 

Describes  the  Current- Year  Plan  for 
IRM;  focuses  on  linking  development 
projects  to  resource  requirements,  func¬ 
tions  supported,  organizational  goals, 
and  project  objectives. 

Describes  in  broad  terms  the  goals  and 
objectives  of  development  projects 
underway  in  the  current  year. 

Summarizes  information  projects  that 
will  be  in  work  during  the  current  year; 
relates  projects  to  supported  functions, 
objectives,  data  bases,  information 
systems,  interface  requirements,  and 
resource  requirements. 
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i  .w  *. 


4.3  INFORMATION  SYSTEMS 

5.  BUDGET-YEAR  PLAN 

6.  LONG-TERM  PLAN 

: 


Presents  a  summary  description  of  infor¬ 
mation  systems  that  are  operating  or  are 
in  the  development  phase;  provides 
information  on  the  source  of  funding  and 
describes  hardware,  software,  data  base, 
and  personnel  requirements;  relates  sys¬ 
tems  to  functions,  development  projects, 
and  interface  requirements. 

Provides  information  on  the  budget  year 
using  the  same  basic  topics  as  the 
Current-Year  Plan. 

Provides  a  Five-Year  Plan  and  an  Out- 
Year  Plan  for  projects  that  are  planned 
to  start  after  the  budget  year  or  for  proj¬ 
ects  that  extend  beyond  the  Budget-Year 
Plan;  uses  the  same  topics  as  the 
Current- Year  Plan  and  the  Budget- Year 
Plan. 


APPENDIX  C:  COMMUNICATIONS  TRAFFIC  MODEL 


C.l  Introduction. 

The  data  communications  processes  of  the  defense  supply  system  are 
extremely  complex.  Data  communications  occur  between  all  of  the  logistics 
activities  of  the  Services  and  Agencies  (S/As)  using  numerous  different  formats  and 
communications  paths. 

Communications  are  defined  in  terms  of  standard  transaction  types  defined  by 
the  Defense  Logistics  Standard  Systems  Office  (DLSSO)  to  permit  communications 
between  these  diverse  sites.  More  than  500  transaction  types  have  been  defined, 
approximately  150  of  which  are  special  transactions  used  by  individual  Services. 
The  remaining  transactions  are  used  for  communications  between  different  organi¬ 
zations. 

The  most  common  communications  path  for  a  transaction  is  from  the  origin  to  a 
Defense  Automatic  Addressing  System  (DAAS)-site  assigned  to  that  origin  and  from 
the  DAAS-site  to  the  destination.  In  some  cases,  communications  do  flow  directly 
from  origin  to  destination. 

The  transmission  of  transactions  between  logistics  sites  is  a  function  of  the  type 
of  site  [depot,  inventory  control  point  (ICP),  transportation,  etc.]  and  the  type  of 
transaction.  For  example,  a  customer  or  retail  site  would  typically  be  the  origin  of 
requisitions  and  the  ICP  would  be  their  destination,  while  Material  Release  Orders 
(MROs)  would  flow  from  an  ICP  to  a  depot. 

Because  of  the  unique  and  complex  characteristics  of  defense  logistics  commu¬ 
nications,  a  data  communications  model  was  considered  necessary  to  support  the 
analysis  of  alternative  system  architectures  and  to  evaluate  the  impact  of  Defense 
Logistics  Standard  Systems  ( DLSS)  changes  on  communications  traffic.  The  unique 


characteristics  of  defense  logistics  communications  precluded  the  use  of  existing 
communications  traffic  models.  While  a  number  of  models  are  commercially  avail¬ 
able,  none  offers  the  capability  of  identifying  different  types  of  traffic  and  associating 
them  with  unique  origins  and  destinations.  Such  a  capability  is  particularly 
important  for  the  analysis  of  the  impact  of  specific  DLSS  changes  on  overall  commu¬ 
nications  system  traffic. 

An  additional  problem  associated  with  the  use  of  existing  models  is  that  their 
outputs  are  presented  in  economic  terms.  Because  of  the  uncertainty  associated  with 
the  tariff  structure  to  be  applied  to  the  use  of  the  Defense  Data  Network  (DDN),  the 
output  of  the  model  must  be  expressed  in  terms  of  general  communications 
characteristics  of  traffic  volumes  (either  bits  of  information  or  packets  of  informa¬ 
tion),  and  the  distances  between  origin  and  destination  of  the  communicating 
locations. 

For  these  reasons,  a  model  of  the  defense  logistics  communications  system  was 
developed.  That  model  is  capable  of  testing  different  communications  network 
architectural  alternatives,  transaction  configurations,  and  sets  of  site  character 
istics.  Its  output  expresses  communications  traffic  between  origins  and  destinations 
and  the  transmission  distances  of  this  traffic.  It  also  provides  the  capability  of  using 
different  tariff  structures  to  evaluate  the  impact  of  these  structures  on  total 
communications  costs.  The  model  outputs  also  identify  the  traffic  on  specific  routes 
between  pairs  of  sites. 

The  following  sections  present  an  overview  of  the  structure  and  operation  of  the 
model. 

C.2  Structure  of  the  Model. 

Figure  C-I  presents  the  overall  flow  of  data  and  processing  within  the  model. 
The  model  has  four  sources  of  input  that  define  the  system  characteristics:  the  site 
characteristics,  the  transaction  characteristics,  the  switching-node  characteristics 


(used  for  the  existing  system  and  the  first  architectural  alternative),  and  the  tariff 
structure. 

The  processing  in  the  model  is  performed  using  origin-destination  (O-D) 
matrices  to  define  the  distances  and  traffic  between  an  origin  site  and  its  desti¬ 
nation.  The  use  of  the  matrix  representation  permits  calculation  of  all  combinations 
of  origins  and  destinations  between  the  sites  being  considered. 

The  model  processes  the  site  and  switching- node  locations  to  assign  sites  to 
switch  nodes.  A  site  is  assigned  to  the  closest  switching  node  to  minimize  commu¬ 
nications  distances.  When  this  assignment  is  completed,  the  distances  between  all 
sites  are  calculated  considering  the  intermediate  routing  through  the  switching 
nodes. 

Traffic  calculations  are  performed  individually  for  each  transaction  type.  The 
processing  calculates  the  O-D  traffic  matrices  for  each  transaction  type  by 
identifying  the  origins  and  destinations  for  each  transaction.  This  identification  is 
performed  using  the  site  characteristics  and  the  definitions  of  possible  origin  and 
destination  site  types  from  the  transaction  data  base.  The  traffic  for  the  current 
transaction  type  is  then  assigned  to  each  of  the  possible  sites  in  proportion  to  the 
total  traffic  at  that  site.  The  traffic  between  origins  and  destinations  is  calculated  in 
proportion  to  the  traffic  proportions  at  the  destination  sites  and  by  using  a  series  of 
factors  that  represent  the  relative  proportions  of  interorganizational  traffic  that 
exists  in  the  system.  From  these  calculations,  O-D  matrices  representing  the  traffic 
between  all  combinations  of  origins  and  destinations  for  a  single  transaction  type  are 
generated. 

When  these  calculations  have  been  completed,  a  final  traffic  O-D  matrix  is 
developed  by  adding  the  values  in  the  corresponding  cells  of  each  of  the  transaction 
matrices.  The  final  traffic  matrix  and  the  distance  matrices  are  used  to  calculate 


communications  costs. 


FIGURE  C-1.  DEFENSE  LOGISTICS  COMMUNICATIONS  TRAFFIC  MODEL  STRUCTURE 


The  outputs  of  the  model  include  both  the  detailed  data  required  for  evaluation 
of  traffic  and  distances  between  specific  origins  and  destinations  and  the  composite 
data  required  for  evaluation  of  system  alternatives.  The  composite  data  includes 
total  system  distances,  total  traffic,  and  total  communications  costs.  These  two 
outputs  —  the  detailed  data  and  the  composite  data  —  permit  the  use  of  the  model  for 
comparison  of  alternatives  and  for  the  detailed  system  analysis  required  to  estimate 
system  elements  such  as  communications  capacities,  switching- node  characteristics, 
and  gateway  processor  (GP)  capabilities. 

C.3  User  Input  Data. 

The  input  data  used  to  define  the  system  architecture  and  traffic  flow  charac¬ 
teristics  for  the  model  include: 

•  Site  Characteristics  —  All  major  sites  of  the  current  logistics  system  are 
included  in  this  data  base.  The  characteristics  used  to  define  each  site 
include  its  name,  state,  type  of  site  (customer,  retail,  ICP,  depot,  etc.), 
organization  [Military  Service,  Defense  Logistics  Agency  (DLA),  General 
Services  Administration  (GSA),  Coast  Guard,  or  other  civilian  agency ],  its 
latitude  and  longitude,  and  time  zone.  The  total  existing  communications 
traffic  entering  and  leaving  this  site,  based  on  Logistics  Information  Data 
Service  (LIDS)  data,  are  also  included  in  this  data  base. 

The  latitude  and  longitude  are  used  for  calculating  communications 
distances;  the  time  zones  are  used  for  the  calculation  of  peak  traffic 
conditions;  and  the  DAAS  sites  are  included  in  the  site  characteristics  data 
base  to  account  for  the  traffic  that  they  originate,  such  as  response  to  source 
of  supply  inquiries. 

A  total  of  91  logistics  sites  are  included  in  this  data  base.  These  sites 
account  for  85  percent  of  the  total  logistics  communications  traffic. 

•  Switching-Node  Characteristics  —  The  switching  nodes  are  the  sites 
through  which  all  communications  traffic  is  routed.  They  are  required  for 
two  of  the  architectural  alternatives,  the  existing  system  and  Alternative  1 
as  described  in  Part  HI,  Chapter  A.  The  two  DAAS  sites  are  treated  as 
switching  nodes  for  both  of  these  alternatives.  The  data  included  in  the 
switching-node  data  base  include  the  site  name,  state,  latitude  and  longi 
tude.  The  latitude  and  longitude  are  used  for  the  calculation  of  commu¬ 
nications  distances  and  for  the  assignment  of  destination  sites  to  specific 
switching  nodes. 


•  Transaction  Characteristics  —  The  characteristics  of  each  of  the  more  than 
500  transactions  are  defined  in  this  data  base.  These  characteristics  include 
the  three-character  alphanumeric  transaction  identifier,  the  transaction 
length  in  bytes  (most  transactions  in  the  existing  system  are  80  bytes  long), 
the  allowable  origins  and  destinations  for  the  transaction,  and  a  growth 
factor  to  account  for  variations  in  transaction  usage  (such  as  future  on-line 
inquiries)  or  modifications  to  transaction  format.  This  data  base  also 
includes  the  total  traffic  for  this  transaction  type. 

These  three  data  bases  are  stored  as  separate  files  that  can  be  modified  by  the 
user.  Differing  architectural  alternatives  can  be  tested  by  changing  the  number  of 
switching  nodes  and  their  locations.  The  effect  of  modifications  to  transaction 
formats  can  be  evaluated  by  changing  transaction  length  and  total  transaction 
volumes. 

Tariff  structure  can  also  be  incorporated  in  the  model  as  a  user  input.  The 
tariff  structure  can  be  defined  in  terms  of: 

•  Cost  as  a  function  of  communications  distance  —  This  variable  is  charac¬ 
teristic  of  the  rate  structure  for  voice  communications  such  as  the  American 
Telephone  and  Telegraph  (AT&T)  long  distance  message  toll  service. 

•  Cost  as  a  function  of  the  total  number  of  communications  ports  at  all 
sites  —  This  cost  is  incurred  as  a  monthly  charge  that  is  related  to  the 
capacity  of  the  port,  the  number  of  ports,  and  the  equipment  required  at 
each  port.  It  also  includes  the  cost  of  access  lines  between  the  local  site  and 
the  data  communications  service.  The  number  of  ports  required  is 
automatically  calculated  by  the  model. 

•  Cost  as  a  function  of  communications  traffic  —  This  cost  is  calculated  as  a 
function  of  the  number  of  kilopackets  of  data  transmitted  between  sites. 
When  switching  nodes  are  included,  the  data  communications  traffic  is 
doubled  to  account  for  the  fact  that  all  data  are  communicated  twice. 

The  variables  that  make  up  the  tariff  structure  are  applied  to  the  final 
estimates  of  traffic  and  communications  distance  produced  by  the  model. 

C.4  Processing  Techniques. 


As  previously  indicated,  all  data  in  the  model  are  represented  as  a  series  of 
matrices  defining  the  communications  characteristics  between  the  origin  and  desti 
nation.  An  additional  set  of  matrices  has  also  been  developed  to  reduce  the  number 


TABLE  C-1.  DEFENSE  LOGISTICS  COMMUNICATIONS  TRAFFIC  MODEL 
TRANSACTION  CONSOLIDATION  MATRIX 

(Values  Shown  are  Monthly  Document  Volumes  in  1 ,000's) 


(FROM) 

CONSOLIDATED  TRANSACTION  TYPE 

DOC  ID 

CUSTOMER 
(TO)  ICP 

ICP  to 

Depot  to 

ICP  to 

Depot  to 

TOTAL 

Customer 

ICP 

Depot 

Transport 

A01 

251 

0 

0 

0 

0 

•  •  • 

755 

A02 

6 

0 

0 

0 

0 

•  »  • 

17 

A04 

4 

0 

0 

0 

0 

•  •  • 

13 

AOS 

0 

0 

0 

0 

0 

•  •  • 

0 

• 

• 

•  •  • 

0 

• 

A21 

0 

6 

0 

0 

0 

•  •  • 

20 

A  22 

• 

• 

• 

0 

0 

0 

0 

0 

•  •  • 

•  •  • 

0 

TOTALS  FOR 
CONSOLIDATED 
TRANSACTIONS 

1,076 

4,225 

1,650 

1,380 

28 

•  •  • 

TOTAL 

of  transaction  types  that  must  be  processed  by  the  model.  The  rows  of  the  trans¬ 
action  consolidation  matrices,  shown  in  Table  C-1,  define  the  existing  transactions 
by  transaction  identifier,  and  the  columns  identify  the  types  of  sites  that  can  serve  as 
origins  and  destinations  for  these  transactions.  For  example,  a  requisition  that 
might  be  transmitted  from  a  customer  to  an  ICP  and  from  a  retail  site  to  an  ICP 
would  be  identified  by  entries  in  the  cells  represented  by  the  appropriate  site  origins 
and  destinations.  All  transactions  with  the  same  origins  and  destinations  are 
combined  into  a  single  transaction  type  for  processing  by  the  traffic  model.  All 
transactions  sharing  a  common  origin  and  destination  are  combined  and  processed 
as  though  they  were  a  single  transaction  type.  Thus,  it  is  only  necessary  to  process 
29  combined  transactions  instead  of  the  500  individual  transaction  types.  The 
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common  characteristic  of  combined  transaction  types  is  that  all  of  the  transactions 
included  have  common  origins  and  destinations. 


The  remaining  processing  within  the  communications  model  is  performed 
using  the  O-D  traffic  matrices  shown  in  Table  C-2.  Those  matrices  are  used  to 
support  each  of  the  processing  steps.  For  example,  processing  of  distances  between 
origin  and  destination  is  performed  using  the  following  steps: 

•  Direct  communications  distances  between  origin  and  destination  (used  for 
Alternative  2  described  in  Part  III,  Chapter  A)  are  calculated  as  the  square 
root  of  the  sum  of  the  squares  of  the  north-south  and  east-west  distances 
between  origin  and  destination.  The  north-south  and  east-west  distances 
are  calculated  using  the  latitudes  and  longitudes  of  the  sites.  This 
calculation  is  performed  for  every  origin  and  destination. 

•  For  the  alternatives  that  include  switching  nodes,  distances  are  calculated 
based  upon  the  distance  between  every  site  and  every  switching  node.  The 
shortest  distance  is  then  selected  and  used  to  represent  the  distance  from 
origin  site  to  switching  node. 


TABLE  C-2.  TYPICAL  DEFENSE  COMMUNICATIONS  TRAFFIC  MODEL 
ORIGIN-DESTINATION  TRAFFIC  MATRIX 

(Shows  typical  document  traffic  in  1,000's  of  documents  for  a  single  document  type) 


ORIGIN 

DESTINATION  SITE  NUMBER 

TOTAL 

ORIGIN 

traffic 

SITE  NUMBER 

1 

2 

3 

4 

5 

« 

• 

• 

1 

0 

1,214. 

62 

158 

12. 

•  •  • 

467 

2 

46 

0. 

400. 

360 

100. 

•  •  • 

2,678 

3 

83. 

219 

0. 

51 

408 

•  •  • 

910 

4 

126. 

46. 

8 

0. 

20 

•  •  • 

260 

5 

• 

• 

• 

62. 

60. 

12 

0. 

0 

•  •  • 

•  •  • 

173 

• 

• 

• 

TOTAL 

DESTINATION 

TRAFFIC 

316 

2,005. 

719 

892 

1,294. 

•  •  • 

5,328 

•  The  distance  between  the  switching  node  (selected  for  the  origin)  and  the 
destination  is  then  added  to  the  shortest  distance  calculated  in  the  previous 
step  to  determine  the  total  communications  distance  from  origin  to 
destination.  This  distance  is  stored  in  the  appropriate  cell  of  the  distance 
O-D  matrix. 

The  traffic  matrices  are  developed  using  the  organization  and  type  of  site 
defined  by  the  site  data  base,  and  the  traffic  volumes  and  site  types  of  the  transaction 
data  base.  The  processing  steps  performed  for  the  calculation  of  the  traffic  matrices 
include: 

•  Calculation  of  the  originating  traffic  from  every  site  for  the  transaction 
type.  This  calculation  is  performed  only  for  those  sites  whose  site  types 
match  the  origin-site  type  of  the  transaction  being  processed.  Traffic  is 
calculated  as  the  product  of  the  percent  of  traffic  produced  by  the  trans 
action,  times  the  actual  traffic  originating  from  the  site. 

•  Calculation  of  the  destination  traffic  at  every  site  for  the  transaction  type. 
This  calculation  is  performed  only  for  those  sites  whose  site  types  match  the 
destination-site  type  of  the  transaction  being  processed.  Traffic  is  calcu 
lated  as  the  product  of  the  percent  traffic  produced  by  the  transaction,  times 
the  actual  traffic  originating  from  the  site. 

•  A  total  traffic  matrix  identifying  transactions  flowing  from  an  origin  to  a 
destination  is  then  calculated  by  proportioning  the  origin  traffic  to  the 
destination  traffic,  as  a  function  of  relative  percent  of  traffic  arriving  at  that 
destination.  An  additional  factor  is  incorporated  reflecting  the  distortion  of 
traffic  patterns  by  the  fact  that  traffic  flows  either  between  DLA  and 
another  organization  or  within  a  given  organization.  For  example,  the 
majority  of  traffic  originating  at  an  Army  site  is  transmitted  either  to 
another  Army  site  or  DLA.  An  insignificant  amount  of  Army  traffic  would 
be  transmitted  to  the  Navy  or  Air  Force. 

•  The  final  step  of  this  process  is  the  calculation  of  a  composite  traffic  matrix 
through  the  cell-by-cell  addition  of  the  individual  traffic  matrices. 

The  communications  system  cost  is  calculated  using  the  distance  and  traffic 
matrices  using  the  following  procedures: 

•  The  number  of  kilopackets  of  information  transmitted  from  each  location  is 
calculated  as  the  total  number  of  transactions  transmitted,  times  the 
average  transaction  length  in  bytes,  times  the  number  of  bits  per  byte.  This 
value  is  used  to  calculate  the  usage  charge  and  the  number  of  ports  at  each 
site. 


•  The  number  of  ports  is  calculated  as  the  number  of  kilopackets  of  infor 
mation,  times  the  bits  per  kilopacket,  times  the  peak  hour  factor,  divided  by 
the  data  rate  of  the  port. 

•  If  a  fractional  number  of  ports  is  calculated,  the  value  is  rounded  up  to  the 
next  highest  value. 

The  usage  values  and  the  number  of  ports  are  then  multiplied  by  the  user- 
supplied  tariffs  to  estimate  the  cost  of  the  service. 

C.5  Applications. 

This  communications  model  has  been  developed  to  serve  as  a  tool  for  evalu 
ating  the  costs  and  capabilities  of  the  defense  logistics  communications  network 
system.  Costs  produced  by  the  model  will  be  used  to  evaluate  the  communications 
cost  associated  with  the  implementation  of  each  of  the  three  communications 
network  architectures  described  in  Part  III.  These  costs  will  be  developed  using  the 
comparable  cost  of  commercial  packet-switched  data  communications  services. 

The  model  will  also  be  used  to  develop  the  refined  costs  of  processing  equipment 
required  to  perform  gateway  and  routing  functions  for  logistics  data.  The  model  will 
support  this  analysis  by  providing  estimates  of  traffic  loading  at  each  site  served  by 
a  communications  processor. 

The  model  can  be  used  to  evaluate  the  impact  of  changes  in  DLSS  data 
standards  on  communications  traffic.  This  evaluation  is  important  for  evaluation  of 
on-line  traffic,  transmission  of  transportation  transactions,  and  transmission  of 
graphics  data,  all  of  which  can  lead  to  significant  increases  in  traffic  loads. 

The  model  can  be  used  to  support  the  logistics  community’s  evaluation  of  the 
impact  of  tariff  structures  proposed  by  the  Defense  Communications  Agency  (DCA) 
for  DDN.  A  number  of  different  approaches  could  be  used  by  DCA  to  define  this 
structure.  It  is  important  to  evaluate  those  costs  before  tariffs  are  finally 


established. 


In  addition  to  these  applications,  the  model  can  be  used  to  evaluate  the  impact 
of  changes  in  logistics  system  operation  on  communications  requirements.  These 
changes  might  include  communications  loads  during  transition  from  peacetime  to 
wartime  logistics  operations  or  a  change  in  the  role  of  a  major  supply  system  instal¬ 
lation. 

Thus,  this  communications  model  is  capable  of  serving  as  a  tool  to  be  used  in 
the  support  of  planning  activities  associated  with  a  changing  logistics  environment. 


APPENDIX  D:  DATA  BASE  MANAGEMENT 


A  large  number  of  data  base  management  systems  (DBMSs)  are  in  the 
marketplace  and,  accelerated  by  the  microcomputer  boom;  that  number  is  increasing 
rapidly.  Today,  without  international,  national,  or  Federal  standards,  virtually 
every  commercial  data  base  product  is  unique.  It  is,  therefore,  appropriate  for  the 
Defense  Logistics  Standard  Systems  (DLSS)  to  consider  defining  standards  for 
DBMSs  used  in  logistics  applications.  The  past  few  years  have  been  productive  for 
DBMS  standardization.  Surveys  of  DBMS-related  standardization  activities  can  be 
found  in  "DBMS  Standardization  —  1979  to  1983,”  Computers  and  Standards, 
Vol.2,  No.  2,  1983,  pp.  119  —  126,  by  T.  W.  Olle.  Such  widespread  activity  is 
essential  for  a  successful  DBMS  standardization  effort. 

This  appendix  discusses  DBMS-related  standardization  efforts  underway.  The 
American  National  Standards  Institute  (ANSI)  proposals  for  data  base  standards  are 
under  critical  review  by  a  special  international  data  base  experts  group  that  will 
make  recommendations  to  its  parent  International  Standards  Organization  (ISO) 
Committee.  Federal  and  Department  of  Defense  (DoD)  representatives  are  active 
participants  on  ANSI  data  base  committees.  It  is  likely  that  international  and 
Federal  standards  will  derive  from,  and  be  consistent  with,  resulting  ANSI  stan¬ 
dards.  It  is  vital  in  the  evolving  logistics  systems  environment  that  DoD  also  recog 
nize,  accept,  and  publish  through  the  DLSS,  the  developing  ANSI  DBMS  standards. 

This  appendix  also  presents  an  introduction  to  data  base  machines  (DBMs). 
The  types  of  DBMs  currently  available  on  the  market  are  categorized  according  to 
the  functions  they  perform  and  their  relation  to  the  host  computer 


The  final  section  of  this  appendix  discusses  prototype  efforts  underway  within 
the  DoD  for  interfacing  heterogeneous  distributed  data  base  management  systems 
(DDBMSs).  This  discussion  supplements  information  provided  in  Part  III, 
Chapter  C. 

D.l  DBMS  Standardization  Efforts. 

This  section  addresses  activities  related  to  DBMS  standardization  including: 

•  Reference  Model  —  provides  a  conceptual  framework  for  the  study  and 
organization  of  DBMS  standards  activities. 

•  Data  Model  —  provides  a  means  for  classifying  and  understanding  imple¬ 
mentations  of  DBMSs.  Some  DBMSs  may  support  multiple  data  models. 

•  Data  Base  Language  —  specifies  the  syntax  and  semantics  of  data  base 
languages  (e.g.,  schema  definition  language  and  data  manipulation  lan 
guage).  The  standards  for  Structured  Query  Language  (SQL)  and  Network 
Database  Language  (NDL)  are  presented  here. 

•  Data  Base  Interchange  Forms  —  facilitates  data  base  translation.  The 
National  Bureau  of  Standards  (NBS)  proposal  for  a  method  for  representing 
the  data  structures  of  the  newly  proposed  network  and  relational  data 
models  is  discussed. 

Figure  D-l  presents  a  breakdown  of  DBMS  components.  The  ANSI/NDL  and 
ANSI/SQL  standards  are  addressing  data  models  and  data  definition  languages  as 
part  of  logical  data  base  standards  efforts.  ANSI  standardization  efforts  are  also 
addressing  host  language  interfaces  under  data  base  interrogation.  Other  compo¬ 
nents  listed  in  Figure  D-  L  are  being  addressed  by  other  standardization  activities. 
D.l. a  Reference  Model  for  DBMS  Standardization. 

The  NBS  has  proposed  a  Reference  Model  (RM)  for  DBMS  standardization.  An 
RM  is  a  conceptual  framework  to  divide  standardization  work  into  manageable 
pieces  and  to  show,  at  a  general  level,  how  those  pieces  are  related  to  each  other.  A 
well-known  example  of  an  RM  is  the  ISO  RM  of  the  Open  Systems  Interconnection 
(OSI)  layered  architecture  discussed  in  Appendix  A,  a  major  tool  for  standards  activ 
ities  relating  to  interprocess  communications. 


FIGURE  D-1.  DATA  BASE  MANAGEMENT  SYSTEM  COMPONENTS 
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Some  of  the  objectives  of  a  DBMS  RM  are: 


•  To  serve  as  a  tool  for  the  development  and  coordination  of  standards  in  the 
DBMS  area.  An  RM  identifies  important  interfaces  that  can  then  be  stan¬ 
dardized  by  appropriate  technical  committees. 

•  To  describe  interactions  between  the  DBMS  and  other  software  components 
in  an  information  system,  such  as  data  dictionary  systems,  report  writers, 
etc.  This,  in  turn,  might  influence  DBMS  vendors  to  provide  plug- 
compatible  components. 

•  To  facilitate  the  training  of  personnel  by  providing  a  common  framework  for 
describing  DBMSs. 

•  To  allow  classification  of  vendor  implementations. 

•  To  aid  users  in  reviewing,  changing,  and  introducing  DBMSs  into  an 
organization. 

Although  the  RM  itself  is  not  a  proposal  for  a  standard,  it  provides  a  basis  for 
considering  future  standards  efforts.  Important  benefits  may  be  achieved  from 
DBMS  standardization  by  users,  purchasers,  computer  service  management  and 
staff,  vendors,  and  DBMS  designers.  Potential  benefits  that  can  be  gained  from  the 
standardization  of  the  DBMS  are: 

•  Mobility  of  applications  and  portability  among  hardware.  If  DBMS 
standards  are  adopted  by  manufacturers  and  vendors,  users  will  be  able  to 
develop  applications  for  use  on  different  computers. 

•  Improved  staff  productivity  and  reduced  training  costs.  The  costs  involved 
in  staff  education  are  high.  If  DBMS  standardization  is  achieved,  costs 
associated  with  reeducation  of  DBMS  users  and  programmers  and  the 
temporary  loss  of  productivity  linked  with  staff  turnover  will  be  reduced. 

•  Simplification  of  DBMS  selection  and  evaluation.  At  present,  the  DBMS 
selection  and  evaluation  process  is  both  complex  and  expensive  and, 
consequently,  is  often  conducted  only  superficially.  Adoption  of  a  limited 
number  of  standards  will  make  the  evaluation  process  simpler. 

•  Reduced  costs.  The  adherence  to  standards  by  vendors  will  lower  the  cost  of 
the  product  in  the  community. 

•  Increased  feasibility  of  data  interchange  between  DBMSs.  The  need  for 
data  generated  from  one  DBMS  to  be  loaded  into  another  DBMS  is  growing. 
The  introduction  of  DBMS  standards  will  make  data  interchange  more 
feasible. 


The  primary  audience  for  the  RM  consists  of  the  ISO  and  ANSI  experts 
involved  in  DBMS  standardization.  The  proposed  RM  is  based  on  the  first  ANSI/ 
Standards  Planning  and  Requirements  Committee  DBMS  framework.  This  frame¬ 
work  describes  a  DBMS  in  terms  of  a  three-schema  architecture:  external  schema 
(user  view),  conceptual  schema  (logical  data  base  design),  and  internal  schema 
(physical  implementation). 

D.l.b  Data  Models  in  the  Selection  and  Use  of  DBMSs. 

Potential  users  need  a  method  for  differentiating  among  the  large  number  of 
DBMS  products  according  to  their  fundamental  capabilities  without  becoming  over¬ 
whelmed  by  highly  specialized  features  of  specific  implementations.  The  concept  of  a 
data  model  provides  such  a  means  for  classifying  and  understanding  implemen¬ 
tations  of  DBMSs.  Fortunately,  many  DBMS  products  are  based  on  a  small  number 
of  data  models  that  have  received  extensive  attention  in  the  research  literature. 

A  data  model  is  a  collection  of  data  structures  together  with  a  collection  of 
operations  that  manipulate  the  data  structures  to  store,  query,  or  process  the  struc¬ 
ture  contents.  A  data  model  may  also  include  the  integrity  constraints  defined  over 
the  data  structures,  or  it  may  include  access  control  facilities  or  mechanisms  for 
defining  various  external  user  views  of  the  data  base.  Some  data  models  provide 
physical  storage  structures  and  physical  access  methods  as  part  of  the  data  model, 
but  a  data  model  is  usually  limited  to  the  data  structures  and  operations  that  are 
available  to  an  end-user  and  may  be  accessed  from  an  application  program. 

A  DBMS  supports  a  data  model  and  is  an  implementation  of  it.  Some  DBMSs 
may  support  multiple  data  models  by  providing  different  user  interfaces  to  the  data 
base.  A  DBMS  provides  for  transformation  of  the  logical  data  structures  of  a  data 
model  to  the  physical  storage  structures  of  a  particular  hardware  environment. 

ANSI  Committee  X3H2  is  currently  working  on  specifications  for  two  models 
that  are  similar  but  not  identical  to  many  existing  products.  The  network  model  is  a 
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structure-oriented  model  especially  suitable  for  data  bases  with  static  structures  and 
a  high  volume  of  record-at-a-time  processing.  The  relational  model  depends  more 
heavily  on  operations  than  structures  and,  thus  provides  the  flexibility  to  handle 
dynamic  data  bases.  Examples  written  in  the  draft  NDL  and  the  Relational 
Database  Language  (RDL)  demonstrate  that  both  models  can  answer  complex 
queries  in  a  straightforward  manner. 

An  important  feature  of  planned  data  base  standards  is  that  no  single  interface 
specification  will  exclude  other  interfaces  between  the  end-user  and  the  data  base. 
For  example,  both  the  NDL  and  RDL  assume  a  programming  language  interface  to 
the  data  and  yet  they  acknowledge  the  existence  of  other  user  interfaces  such  as  ad 
hoc  query  and  report  writer  languages,  schema  manipulation  languages  or  data 
dictionary  interfaces,  special  transaction-processing  systems  that  take  advantage  of 
modern  screen  and  graphics  capabilities,  and  bulk  loading  or  unloading  facilities 
both  for  data  base  back-up  and  for  data  base  information  interchange.  Language 
specifications  for  these  additional  capabilities  are,  at  present,  unique  to  each  DBMS 
vendor.  If  and  when  standard  specifications  become  available,  they  should  be 
upwardly  compatible  with  established  data  model  standards. 

While  there  are  far  more  data  models  than  the  ,wo  currently  in  the  process  of 
standardization,  most  others  are  either  structure-oriented  like  the  network  model  or 
operation-oriented  like  the  relational  model.  Particular  vendors  have,  in  many 
cases,  developed  tools  or  features  that  compensate  for  some  of  the  limitations 
inherent  in  the  data  model  underlying  their  products.  The  still  difficult  job  is  to 
match  the  features  of  a  proposed  DBMS  with  the  particular  application  require¬ 
ments  of  the  users. 


D.l.c  Data  Base  Language  Standards. 

This  section  discusses  two  data  base  language  standards  proposed  by  ANSI 
Committee  X3H2,  the  SQL  and  the  NDL  standards. 


The  SQL  standard  specifies  the  syntax  and  semantics  of  interfaces  to  DBMSs 
for  defining  and  accessing  SQL  data  bases.  Two  data  base  languages  are  specified: 

•  A  schema  data  definition  language  [DDL  (SQL-DDL)],  for  declaring  the 
structures  and  integrity  constraints  of  an  SQL  data  base 

•  A  module  language  and  a  data  manipulation  language  [DML  (SQL-DML)], 
for  declaring  the  data  base  procedures  and  executable  statements  of  a  spe¬ 
cific  data  base  application. 

The  SQL  standard  specifies  functional  capabilities  for  designing,  accessing, 
maintaining,  controlling,  and  protecting  the  data  base.  It  also  provides  a  vehicle  for 
portability  of  data  base  definition  and  application  modules  between  conforming 
systems. 

The  SQL  standard  applies  to  implementations  that  exist  in  an  environment 
that  may  include  application  programming  languages,  end-user  query  languages, 
report  generator  systems,  data  dictionary  systems,  program  library  systems,  and 
distributed  communication  systems  as  well  as  various  tools  for  data  base  design, 
data  administration,  and  performance  optimization. 

The  NDL  standard  specifies  the  syntax  and  semantics  of  three  data  base 
languages: 

•  A  schema  definition  language  for  declaring  the  structures  and  integrity 
constraints  of  an  NDL  data  base 

•  A  subschema  definition  language  for  declaring  a  user  view  of  that  data  base 

•  A  module  language  including  DML  for  declaring  the  data  base  procedures 
and  executable  statements  of  a  specific  data  base  application. 

The  NDL  standard  specification  constitutes  a  definition  of  the  logical  data 
structures  and  basic  operations  for  an  NDL  data  base.  It  provides  functional 
capabilities  for  designing,  accessing,  maintaining,  controlling,  and  protecting  the 


D.l.d  DBMS  and  Data  Base  Portability  —  Approaches  to  Data  Base  Translation. 

Transporting  a  data  base  from  a  source  to  a  target  environment  has  often  been 
an  expensive  and  complex  project.  In  large  part  this  expense  and  complexity  are  due 
to  the  lack  of  standards  for  data  models  and  data  base  interchange  forms.  An  NBS 
report1  describes  approaches  to  data  base  translation,  discusses  candidate  inter 
change  forms,  and  recommends  a  method  for  representing  the  data  structures  of 
newly  proposed  network  and  relational  data  models  in  a  form  suitable  for  data  base 
interchange.  Methods  for  representing  other  commonly  used  data  base  structures  in 
terms  of  the  proposed  standard  structures  show  that  automated  data  base  trans¬ 
lation  is  feasible  for  most  currently  installed  data  models. 

The  entire  process  of  transporting  an  application  system  from  one  environment 
to  another  while  maintaining  the  functional  requirements  of  the  original  system  is 
termed  conversion.  The  conversion  process  consists  of  a  number  of  different  phases, 
including  planning,  data  preparation,  and  testing;  however,  the  essence  of  conver¬ 
sion  is  the  translation  phase  in  which  the  actual  source-to-target  transfer  occurs. 
When  a  DBMS  is  involved,  the  conversion  process  is  complicated,  primarily  because 
the  DBMS  imposes  a  structure  on  the  data  and  on  data  manipulation.  The  situation 
is  further  complicated  because  no  standard  DBMSs  exist  and  consequently  few 
general  conversion  tools  are  available.  Each  conversion  to  or  from  a  DBMS  tends  to 
be  a  unique  situation. 

The  required  resources  and  accrued  costs  associated  with  data  base  translation 
are  closely  related  to  the  dissimilarities  of  the  data  models  of  the  source-and-target 
environments,  the  availability  of  automated  translation  aids,  and  the  experience  of 


1 L.  Gallagher  and  S.  Salager,  Report  on  Approaches  to  Database  T ranslation,  XBS  SP  500- 1  5, 
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the  conversion  personnel.  The  following  situations  are  prime  factors  affecting  the 
costs  of  data  base  translation: 

•  No  general-purpose  data  base  translation  aids  (e.g.,  documented  software 
packages  or  "turnkey”  products)  that  have  effective  applicability  to 
multiple  translation  environments  are  currently  available.  Each  organi¬ 
zation  is  required  to  design,  develop,  test,  and  document  the  aids  needed  for 
a  particular  conversion. 

•  Translation  aids  that  do  exist  are  usually  tailored  to  very  specific  souree- 
and-target  combinations. 

•  The  lack  of  translation  aids  forces  many  data  base  conversions  to  depend  on 
specially  developed,  one-time  aids  constructed  in-house  or  under  contract. 

•  Translation  experience  among  agency  personnel  is  often  acquired  through 
"live-and-learn,”  on-the-job  conversion  projects.  In-house  learning  experi¬ 
ences  are  often  expensive  especially  since  data  base  translation  can  be  very 
complex. 

•  Translation  frequently  requires  detailed  expertise  with  the  data  handling 
conventions  of  two  systems  —  the  source  system  and  the  target  system.  In 
most  data-processing  shops,  the  degree  of  competence  is  high  for  any  given 
system  but  diminishes  as  the  scope  extends  beyond  that  one  system. 

•  DBMS  and  data  base  translation  standards  are  not  available.  There  is  no 
standard  DBMS  that  may  be  incorporated  to  circumvent  the  costs  and 
complexities  associated  with  data  base  translation.  Also,  there  are  no 
standard  "unload”  and  "load”  methodologies  adhered  to  by  the  various  data 
base  management  packages  on  today’s  market. 

The  focus  here  is  restricted  to  one  area  of  the  translation  phase  of  conversion  in 
a  data  base  environment,  namely  data  base  translation.  The  NBS  report  deals  with 
transferring  data  and  data  definitions  from  a  source,  which  can  be  either  a  batch  file 
system  or  a  DBMS,  to  a  target  DBMS.  It  does  not  consider  application  program 
translation,  discussed  in  the  next  section,  which  deals  with  expressing  and  convert¬ 
ing  operations  on  the  data.  Although  not  explicitly  addressed  here,  a  general 
purpose  data  base  translation  approach  may  be  useful  in  a  distributed  data  base 
environment  involving  heterogeneous  DBMSs. 

An  example  of  user  and  vendor  interest  in  a  generalized  approach  to  data 
exchange  is  the  Initial  Graphics  Exchange  Specification  (IGES).  IGES  is  a 


communication  file  structure  for  data  produced  on  and  used  by  computer-aided 
design  (CAD)  and  computer-aided  manufacturing  (CAM)  systems.  This  structure 
provides  a  common  basis  for  the  automatic  interchange  of  data  between  interactive 
graphics  design-drafting  systems,  for  the  transfer  of  data  to  and  from  external 
application  programs,  and  for  archiving  the  data.  The  IGES  project  is  an  organized 
effort  of  both  Government  and  industry,  on  a  national  level,  to  resolve  interface 
problems  by  introducing  a  set  of  specifications  for  standard  data  structures  and 
formats.  That  users  and  vendors  alike  recognize  the  value  of  this  response  to  the 
data  exchange  problem  is  demonstrated  by  the  rapid  acceptance  of  IGES  as  an 
American  National  Standard. 

In  a  similar  manner,  standardization  of  data  models  of  an  interchange  form 
(ICF)  and  of  intermodel  mappings  would  alleviate  some  of  the  difficulties  involved  in 
developing  general-purpose  software  for  data  base  translation.  Standardization  of 
an  ICF  would  facilitate  specification  of  intermodel  mappings,  because  the  mappings 
could  be  defined  in  terms  of  the  ICF  structures.  Standardization  of  an  ICF  implies 
standardization  of  data  models  because  ICF  structures  are  to  be  defined  along  with 
rules  for  their  correspondence  with  data  structures  of  specific  data  models.  Proposals 
for  a  network  model  and  a  relational  model  currently  under  consideration  by  ANSI 
Committee  X3H2  are  discussed  above. 

Several  candidates  to  serve  as  the  common  ICF  include: 

•  The  Structured  Data  Interchange  Form  proposed  by  James  P.  Fry  and 
Associates  at  the  University  of  Michigan 

•  The  Data  Descriptive  File  (DDF)  advanced  by  ANSI  Technical  Committee 
X3L5  and  ISO  TC97/SC15 

•  The  Data  Extraction,  Processing,  and  Restructuring  System  (EXPRESS) 
designed  by  Robert  W.  Taylor  and  researchers  at  International  Business 
Machines  Corporation  (IBM)  Research  Laboratory 

•  The  Data  Interchange  Form  used  by  several  personal  computer  software 
vendors 


•  The  specification  for  the  Data  Interchange  at  the  Application  Level  (DIAL) 
under  development  within  the  British  Standards  Institution 

•  The  Standard  Format  Data  Unit  project  under  development  by  the  National 
Aeronautics  and  Space  Administration  (NASA)  and  other  national  space 
agencies. 

NBS  concluded  that  each  candidate  ICF  is  incomplete  and  cannot  be  used  for 
general  data  base  translation  without  additional  specification.  Each  of  these 
candidates  has  characteristics  that  make  it  potentially  suitable  as  a  data  base  ICF 
although  some  are  much  more  general  or  flexible  than  others.  Some  forms  require 
specific  implementation  details  to  describe  how  the  data  structures  are  laid  out  in 
linear  form;  others  require  additional  specifications  for  mapping  specific  data  base 
data  structures  to  the  candidate  ICF. 

Use  of  the  DDF  form  is  favored  because  it  is  already  near  acceptance  as  an 
ANSI  and  ISO  standard.  Much  development  time  and  effort  can  be  saved  by  using 
this  existing  and  familiar  form  whenever  possible.  Use  of  the  DDF,  together  with 
the  data  base  representation  rules  specified  in  the  NBS  report,  provides  a  complete 
specification  for  representing  proposed  standard  data  base  structures  in  a  linear 
form  that  can  be  transported  among  heterogeneous  data  base  installations.  Accep¬ 
tance  of  a  general  data  base  ICF  will  ensure  more  rapid  development  of  additional 
conversion  tools,  such  as  vendor-supplied  functions  for  loading  and  unloading  data 
bases  into  standard  formats  and  sophisticated  model-to-model  mapping  capabilities. 
If  users  anticipate  future  conversions  when  selecting  systems,  they  can  require 
vendors  to  provide  data  structures  compatible  with  standard  data  models  and 
automatic  tools  for  convenient  production  and  transmission  of  those  structures  via 
standard  ICFs. 

The  DDF  ICF  was  never  intended  to  be  a  highly  efficient  representation  for  use 
in  real-time  data  interchange.  Acceptance  of  the  DDF  as  one  vehicle  for  data  base 
translation,  especially  for  archival  purposes  or  for  occasional  data  exchange,  should 


not  stifle  development  of  other  forms  that  may  be  more  suitable  or  offer  greater 
efficiency  for  specific  applications  or  in  special  environments.  In  particular,  work  on 
standard  forms  for  data  interchange  in  OSI  will  continue  within  Federal,  ANSI,  and 
ISO  standardization  committees. 

Acceptance  of  standard  data  models  and  general  data  base  ICFs  could  produce 
substantial  benefits  to  DBMS  users  in  terms  of  cost  savings  and  increased  flexibility. 
Subsequent  vendor-supplied,  automated  tools  for  reading  and  writing  data  base 
structures  into  standard  forms  for  interchange  would  make  data  sharing  among 
nonhomogeneous  installations  a  convenient  and  inexpensive  operation. 

D.l.e  The  Navy  Inventory  Control  Point  (ICP)  Portability  Study. 

In  addition  to  issues  pertaining  to  data  base  translation,  several  studies  are 
underway  in  DoD  to  address  the  portability  of  DBMSs  and  application  programs. 
The  Navy  ICP  approach  is  discussed  here.  Problems  in  this  approach  are  experi¬ 
enced  in  three  areas:  the  data  model  of  the  DBMS  that  is  used  to  manage  the  data 
base,  hidden  semantic  differences,  and  the  magnitude  of  requirements  of  applica¬ 
tions  in  a  real  operating  environment. 

If  the  data  model  of  the  target  DBMS  is  different  than  the  data  model  of  the 
existing  DBMS,  significant  problems  may  arise.  The  most  serious  problem  is  the 
fundamental  difference  in  the  way  different  DBMS  models  manage  relationships 
between  records  of  the  same  and  different  types. 

The  goal  of  the  Naval  Supply  Systems  Command  (NAVSUP)  since  it  acquired 
its  current  hardware  is  to  define  how  to  achieve  its  best  use.  DBMSs  are  a  critical 
component  of  the  NAVSUP  effort.  Over  the  years,  only  one  of  the  four  popular 
DBMS  data  models  has  been  widely  used  on  different  computer  hardware  (IBM. 
UNIVAC,  Honeywell,  etc.).  This  DBMS  data  model  concept  is  called  CODASYL 
(Conference  on  Data  Systems  Language). 


D-12 


A  NAVSUP  study  examined  a  representative  sampling  of  DBMSs  that 
subscribe  to  the  CODASYL  data  model  concept  to  determine  the  most  portable 
subset  of  facilities  within  this  concept.  Table  D-l  presents  the  relative  levels  of  effort 
for  converting  from  various  CODASYL-based  DBMSs  to  a  different  CODASYL- 
based  DBMS. 


TABLE  D-1.  RELATIVE  LEVELS  OF  EFFORT  FOR  DATA-BASE  APPLICATION  CONVERSION 


DBMS 

CONVERTED 

FROM: 

DBMS  CONVERTED  TO: 

Network 

Hierarchical 

IND  LOG  File 

Relational 

Total 

IDMS-static 

IMS 

S2K 

ADABAS 

FOCUS 

IDMS-dynamic 

TOTAL 

N/A 

3 

4 

4 

4 

4 

5 

IDMS-static 

3 

N/A 

4 

4 

4 

4 

5 

IMS 

a 

3 

N/A 

3 

4 

4 

5 

S2K 

4 

3 

3 

N/A 

4 

4 

3 

ADA8AS 

4 

4 

4 

4 

N/A 

3 

3 

FOCUS 

4 

4 

4 

4 

3 

N/A 

4 

IDMS-dynamtc 

4 

3 

4 

4 

3 

3 

N/A 

'  No  change 

j  2  Only  syntax  changes 

3  New  syntax  and  significant  semantics  changes 

4  Both  data  base  and  application  modification 

5  Complete  application  redesign  and  implementation 

In  addition,  since  the  Navy  acquired  the  DBMS,  a  subscriber  to  this  CODASYL 
data  model  concept,  the  Navy  study  recommends  a  specific  subset  of  the  IDMS/ 
Relational  facilities  that  should  be  utilized  to  maximize  portability  while  at  the 
same  time  enabling  fully  functional  data  base  applications.  The  recommended 

I 

subset,  therefore,  includes  facilities  which,  while  not  portable,  are  required  for  com- 

■  plete  DBMS  functionality. 

I 

I 
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Since  the  NAVSUP  study  concentrated  on  issues  surrounding  porting  data 
bases  of  DBMSs  that  all  subscribed  to  the  same  data  model  concepts  (CODASYL), 
the  portability  analysis  was  able  to  concentrate  on  detailed  issues  of  syntax  and 
semantics.  Most  features  that  were  portable  are  contained  in  the  ANSI/NDL  specifi¬ 
cation,  which  covers  the  syntax  and  semantics  of  the  schema  including  record  types, 
data  elements,  and  relationships  that  relate  record  types. 

We  make  four  recommendations.  First  and  most  important,  data  base  applica¬ 
tions  should  be  as  DBMS-  and  computer-independent  as  possible  to  maximize  future 
portability.  That  is,  they  should  be  designed  to  mirror  the  natural  business  needs  of 
the  organization  that  they  serve  and  be  designed  using  top-down,  policy-based,  data 
base  project  methodology.  Applications  will  be  in  their  simplest  form,  and  will  be 
more  portable  than  if  they  had  been  designed  always  to  achieve  the  maximum 
performance  capabilities  of  the  DBMS  or  the  computer. 

Second,  the  Navy  and  the  U.S.  Government  should  pursue  the  standardization 
of  the  ANSI/NDL  and  the  ANSI/SQL  data  models  so  that  future  conversions  will  be 
able  to  cite  standards  rather  than  concepts. 

Third,  the  Navy  should  procure  only  DBMSs  that  are  as  close  as  possible  to  the 
ANSI/NDL  and  the  ANSI/SQL  data  models  since  those  data  models  represent  the 
only  network  and  relational  data  model  standards  that  have  been  developed  with  the 
support  of  all  the  major  hardware  vendors  —  with  standardization  in  mind. 

Fourth,  the  Navy  should  advocate  the  development  of  an  ANSI/4GL  (Fourth- 
Generation  Language),  that  accesses  both  the  ANSI/NDL  and  the  ANSI/SQL.  Since 
some  vendors  have  already  developed  a  common  4GL  to  access  their  relational  and 
network  products,  and  since  some  of  the  CULLINET  4GL  languages  access  both  the 
network  and  relational  facilities,  the  concept  is  certainly  proven.  Most  increases  in 
programmer  productivity  for  the  foreseeable  future  will  be  through  these  types  of 
languages,  and  since  the  number  of  automated  systems  will  increase,  it  follows  that 


to  have  an  ANSI/4GL  would  make  future  NAVSUP  application  development  efforts 
both  more  productive  and  more  portable.  Without  an  ANSI/4GL  standard,  major 
development  efforts  will  have  to  remain  in  Common  Business  Oriented  Language 
(COBOL),  with  the  use  of  4GL  restricted. 

D.2  An  Introduction  to  Data  Base  Structure  and  Data  Base  Machines. 

The  development  of  DBMSs  has  been  governed  by  five  management  objectives: 

•  To  maximize  data  independence,  or  to  provide  the  ability  to  separate  data 
from  programs  that  access  and  manipulate  the  data  to  provide  flexibility  — 
Data  independence,  in  its  highest  form,  allows  a  user  to  change  data,  add  or 
delete  categories,  and  reshape  the  data  base,  without  rewriting  data 
management  programs. 

•  To  ensure  integrity  and  consistent  quality  of  data  in  the  system  —  In  a 
high-speed  system  with  frequent  data  updates  and  many  users,  this  task 
can  be  very  complex. 

•  To  maintain  intrasystem  security  —  This  issue  becomes  increasingly 
sensitive  when  a  single  computer  is  shared  by  many  agencies  and  their 
respective  personnel.  When  users  of  remote  terminals  can  dial-up  and 
access  data,  ensuring  data  security  is  essential. 

•  Support  multiple-user  access  to  integrated  data  -  A  system  must  be 
structured  so  that  authorized  new  users  have  access  to  data  manipulation 
facilities  needed  to  perform  their  jobs,  while  reducing  the  risk  of  excessively 
redundant  data  files  and  data  manipulation  that  is  highly  consumptive  of 
computer  resources. 

•  Central  control  of  the  data  base  —  Authorized  personnel  must  be  able  to 
control  the  quality  and  integrity  of  a  data  base. 

These  five  objectives  of  data  management  frequently  produce  conflicts  that 
must  be  resolved  or  balanced.  Many  possible  combinations  of  hardware  and  software 
have  been  devised  to  achieve  these  objectives.  DBMSs  can  be  compared  by  four  basic 
criteria:  (1)  response  time  to  queries/updates,  (2)  size  of  data  base  that  can  be 
supported,  (3)  flexibility  for  handling  varying  data  types,  and  (4)  other  features  that 
can  affect  performance  (for  example,  security  controls,  which  can  slow  down  a 
system). 


In  a  few  rare  cases  an  application  is  so  well  defined  and  insulated  from  other 
applications  that  the  data  base  will  not  change.  In  practice,  however,  most  of  the 
time  an  initial  appearance  of  stability  proves  to  be  deceptive.  Some  DBMSs  are 
designed  around  these  criteria.  Others  are  not  designed  to  facilitate  change  and  do 
not  provide  for  the  processing  of  data  in  a  manner  other  than  that  in  which  they  are 
organized.  These  latter  systems  do  not  permit  data  to  be  restructured  without  conse¬ 
quent  upheavals  in  the  programs  that  use  them. 

Hierarchical  or  network  DBMSs  can  be  fast,  but  a  user  is  often  expected  to 
know  exactly  where  the  desired  information  is  stored  in  the  system.  Hierarchical 
and  network  systems  perform  well  on  static  data  bases  with  relatively  predictable 
queries  and  are  suitable  for  many  archival  or  static  applications.  However,  such 
DBMSs  have  not  kept  pace  with  end-user  demands  for  new  applications.  They 
require  considerable  time  to  program.  Programmers  must  understand  the  environ¬ 
ment,  the  data  and  their  uses,  and  exactly  how  to  structure  the  data  before  they  can 
write  the  computer  program  code.  They  typically  require  reprogramming  when  data 
or  user  needs  change  or  when  the  host  computer  changes. 

Unlike  traditional  data  base  models,  the  relational  data  base  model  accommo¬ 
dates  all  data  in  tables;  the  programmer  or  user  need  not  memorize  complex  pointer 
schema  or  links  to  navigate  through  the  data  bases.  The  relational  approach  also 
creates  data  independence,  meaning  that  the  programs  that  control  physical  storage, 
allocation,  and  data  management  do  not  depend  on  the  amount  or  kind  of  data  in  the 
data  base.  Data  independence  from  programs,  in  turn,  allows  the  user  to  change 
types  of  data  in  data  bases  or  to  add  data  to  data  bases  without  needing  to  rewrite 
data  base  management  software.  This  is  a  flexible,  expandable  DBMS  that  nonpro¬ 
grammers  (as  well  as  computer  specialists)  can  easily  and  efficiently  use. 

While  relational  DBMSs  have  advantages  over  conventional  systems,  they  still 
face  liabilities  when  measured  against  the  objectives  of  DBMSs  and  the  criteria  for 
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comparing  them.  The  relational  DBMS  is  a  heavy  user  of  computing  resources, 
particularly  for  large  data  bases.  A  typical  mainframe-based  application  will 
require  4  to  16  megabytes  of  main  memory  and  several  gigabytes  of  secondary  (disk) 
storage.  Moreover,  the  DBMS  is  likely  to  dominate  the  central  processing  unit 
(CPU)  during  periods  of  heavy  demand,  as  it  translates  user  queries  into  data  access 
commands,  searches  the  secondary  storage  for  the  records  that  satisfy  user  require¬ 
ments,  and  frames  a  reply  to  the  user’s  terminal  or  printer. 

D.2.a  Back-End  Processing. 

Designers  have  faced  these  liabilities  head  on,  primarily  in  creating  a  variety 
of  DBMs  that  act  as  back-end  processors,  relieving  the  host  computer  of  the  burden  of 
physical  data  management.  The  back-end  DBM  is  a  computer  or  processor  specif¬ 
ically  utilized  to  perform  the  data  base  management  task  for  some  other  host 
computer  or  intelligent  terminal.  This  host  processor  is  frequently  called  the  front- 
end  and  the  data  base  processor  is  referred  to  as  a  back-end  computer.  The  back-end 
DBM  is  not  intended  to  be  an  independent  computer;  it  reacts  to,  and  is  controlled  by, 
a  host  computer. 

Back-end  processing  is  a  fundamental  system  approach  designed  to  improve 
performance  and  decrease  the  cost  of  data  management.  Back-end  processing 
involves  special  software  on  a  CPU  or  a  DBM  located  between  a  host  computer  and 
the  disk  storage  devices,  as  depicted  in  Figure  D-2. 

The  performance  of  DBMSs  employing  hierarchical,  network,  or  relational 
data  base  organizations  can  be  enhanced  significantly  by  the  use  of  back-end 
processing.  There  are  three  types  of  back-end  processors:  virtual  DBMs,  dedicated 
DBMs,  and  specialized  DBMs. 

•  The  virtual  DBM  is  a  general-purpose  computer  combined  with  a  software 
package  to  function  as  the  DBMS.  A  virtual  machine  is  a  low-cost  system 
because;  (1)  a  general-purpose  CPU  is  employed,  and  (2)  data  base  manage 
ment  functions  are  shared  with  other  functions  such  as  compilation  and 
transaction  rates. 
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FIGURE  D-2.  BASIC  DATA  BASE  MACHINE  CONFIGURATIONS 
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•  The  dedicated  processor  is  used  exclusively  to  perform  data  base  manage¬ 
ment  functions.  It  is  a  general-purpose  CPU,  but  it  is  physically  distinct 
from  the  host  CPU  and  is  only  required  to  support  data  base  management 
functions.  The  speed  and  efficiency  of  the  dedicated  DBMS  processor 
provides  response  times  for  queries  or  updates  of  the  data  base  that  are 
generally  shorter  than  those  for  the  virtual  machines. 

•  The  "specialized”  DBM  is  specifically  optimized  to  handle  the  functions  of 
data  base  and  disk  management.  The  concept  of  a  specialized  back-end 
DBM  takes  maximum  advantage  of  the  data  independence,  which  is  a 
unique  feature  of  relational  systems.  Further,  such  a  machine,  with  the 
capability  of  specialized  hardware  support,  promises  to  improve  perfor 
mance  in  supporting  large,  complex  data  bases  in  an  interactive  environ¬ 
ment. 

No  one  DBM  is  best  for  executing  all  types  of  queries,  and  DBMs  are  not  cost- 
effective  if  the  application  supported  is  mainly  overhead-intensive.  For  example. 


NBS  is  still  involved  in  testing  back-end  DBMs  because  they  have  not,  to  date, 
proven  themselves  in  large  systems  with  many  sites. 

D.3  Heterogeneous  Distributed  Data  Base  Management  Efforts. 


This  section  discusses  four  prototype  development  efforts  currently  underway 
in  the  DoD  for  interfacing  heterogeneous  DDBMS.  A  fifth  effort  under  development 
at  NBS  and  sponsored  in  part  by  the  Navy  is  also  reviewed.  The  area  of  hetero¬ 
geneous  DDBMS  interfaces  is  experimental  at  this  time,  and  all  efforts  are  initially 
addressing  retrieval  capabilities.  It  will  be  some  time  before  efforts  will  address  the 
issue  of  updating  heterogeneous  DDBMSs. 

D.3. a  Army’s  MULTIBASE  Prototype. 

The  Compi’ter  Corporation  of  America  (CCA)  has  a  contract  with  the  Army 
Materiel  Command  (AMC)  to  develop  a  MULTIBASE  front-end  to  two  data  bases 
resident  on  IBM  mainframes  (System  2000  DBMS  and  the  Army’s  home-grown  Data 
Manager  Routine).  'Intellect”  will  be  used  as  a  natural  language  front-end  to 
generate  Daplex  (a  semantic  data  model  query  language)  commands  to  be  read  by 
MULTIBASE.  MULTIBASE  will  run  under  the  Digital  Equipment  Corporation 
VAX/VMS  operating  system  and  a  gateway  (hyperchannel)  will  be  developed  to 
interface  the  VAX  11/780  to  the  IBM  hosts  using  the  NEDEX  hyperchannel  protocol 
as  the  interface  standard.  The  VAX  is  to  be  accessed  over  ARPANET  [(Defense) 
Advanced  Research  Projects  Agency  Network],  The  VAX  at  the  Automated  Logis¬ 
tics  Management  Systems  Activity  (ALMSA)  in  St.  Louis,  Missouri  will  be  used  for 
development  of  the  system,  with  full  production  to  be  implemented  on  the  VAX  at 
the  Armament  Munitions  and  Chemical  Command  at  Rock  Island  Arsenal  in 
Illinois.  The  IBMs  are  also  located  at  Rock  Island,  Illinois.  A  full  Ada  language 
conversion  for  MULTIBASE  is  being  funded  by  AMC.  A  number  of  performance 
enhancements  will  be  made,  including  the  addition  of  a  query  interrupt  capability. 


D.3.b  Air  Force  Integrated  Design  Support  System. 

A  demonstration  MULTIBASE  prototype  was  to  be  completed  by  the  end  of 
Fiscal  Year  1986  under  a  2-year  contract.  The  system  will  be  implemented  on  a 
VAX  11/780.  Questions  as  to  technical  feasibility,  security  considerations,  and  data 
dictionary  incompatibilities  must  yet  be  addressed.  The  data  dictionary  is  expected 
to  require  between  1  and  10  gigabytes  of  storage.  Other  considerations  include 
network  transaction  management  capability,  file  transfer,  executive  control  system, 
and  rules  for  configuration  management.  Some  of  these  issues  will  be  addressed  in 
the  prototype,  but  the  prototype  will  not  solve  all  the  issues  and  is  expected  to 
identify  additional  ones. 

Response  time  is  an  issue  in  any  MULTIBASE  implementation.  Performance 
has  not  yet  been  addressed  since  resources  have  been  committed  to  the  development 
of  other  system  features.  As  an  interim  measure,  however,  MULTIBASE  can  pro¬ 
vide  the  user  community  with  an  ad  hoc  means  to  generate  reports  that  today  take 
6  months  to  more  than  a  year  from  request  through  implementation. 

D.3.c  NBS  Integrated  Manufacturing  Distributed  Data  Base  Administration. 

The  object  of  this  NBS  project  is  to  identify  and  exercise  potential  standard 
interfaces  between  existing  and  future  components  of  small  batch  manufacturing 
systems.  It  will  also  provide  a  laboratory  for  the  development  of  factory-floor 
metrology  in  an  automated  environment,  delivering  proven  measurement  tech 
niques  and  standard  reference  materials  to  American  industry.  Commercially  avail 
able  products  are  being  used  whenever  possible  to  construct  the  facility  in  order  to 
expedite  transfer  of  research  results  into  the  private  sector.  This  project  is  of  partic 
ular  interest  because  of  the  software  being  developed  to  support  interfaces  to  a 
number  of  heterogeneous  types  of  hardware. 

The  July  1986  prototype  included  interfaces  between  the  VAX  11/785  computer 
and  a  SUN  6800  computer  supporting  the  RIM  (Boeing  Computer  Service's 


Relational  Information  Manager)  and  INGRES  (Relational  Technology,  Inc. 
relational  DBMS)  DBMSs,  as  well  as  flat  file  structures.  Additional  SUNs  will  be 
added  as  well  as  an  interface  to  the  IBM  4341  supporting  SQL.  The  SUN,  VAX,  and 
IBM  computers  also  support  a  variety  of  manufacturing  hardware. 

D.3.d  Air  Force  Integrated  Information  Support  System. 

The  testbed  environment  for  this  Air  Force  system,  as  initially  developed  by 
General  Electric,  as  the  prime  contractor,  and  currently  physically  located  at  the 
Arizona  State  University,  includes  an  IBM  computer  with  IDMS  as  the  DBMS,  and  a 
VAX  11/780  using  ORACLE  as  the  relational  DBMS.  A  prototype  is  complete  with 
interfaces  to  these  two  computers  and  DBMS  configurations.  Structural  Dynamics 
Research  Corporation  is  the  major  subcontractor  who  developed  the  user  virtual 
terminal  interface  for  this  effort.  It  also  has  expertise  in  the  area  of  CAD.  Control 
Data  Corporation  is  responsible  for  the  development  of  the  common  data  model 
processor  that  provides  a  neutral  language  for  a  single  relational  view  across 
multiple  DBMSs. 

A  number  of  vendors  are  interested  in  joining  this  effort.  As  a  result,  various 
additional  hardware  configurations  will  be  added  to  the  testbed,  including  Tandem, 
Hewlett-Packard,  IBM  4341  and  IBM  4381-XA,  and  Cyber  205. 

D.3.e  Naval  Postgraduate  School  Multi-Lingual  Data  Base  System  (MLDS). 

In  MLDS  the  user  does  not  have  to  convert  a  transaction  from  one  data 


language  to  another.  MLDS  permits  the  user  to  run  data  base  transactions  written 
in  different  data  languages.  Hence,  the  user  does  not  have  to  perform  either  a 
manual  or  automated  translation  of  an  existing  transaction  to  execute  the  trans¬ 
action  in  MLDS. 
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APPENDIX  E.  GLOSSARY  OF  TERMS 


The  following  is  a  list  of  acronyms  and  their  definitions  used  in  this  report. 


ACO 

ADAM 

ADP 

ADPSO 

AFLC 

ALC 

ALMSA 

AMC 

AMCL 

ANSI 

ARPANET 

AT&T 

ATCMD 

AUTODIN 

AUTOVON 


Administrative  Contracting  Officer 

Aerial  Port  Documentation  and  Management 

Automatic  Data  Processing 

Automatic  Data  Processing  Support  Office 

Air  Force  Logistics  Command 

Air  Logistics  Center 

Automated  Logistics  Management  Systems  Activity 

Army  Materiel  Command 

Approved  MILSTRIPl  Change  Letter 

American  National  Standards  Institute 

(Defense)  Advanced  Research  Projects  Agency  Network 

American  Telephone  and  Telegraph 

Advance  Transportation  Control  and  Movement  Data 

Automatic  Digital  Network 

Automatic  Voice  Network 


bps 


bits  per  second 


CAD 

CALS 

CAM 

CCA 

CCSS 

CDC 

CDR 

CINC 

COBOL 

CODASYL 

CONUS 

CPU 


Computer-Aided  Design 
Computer-Aided  Logistics  Support 
Computer-Aided  Manufacturing 
Computer  Corporation  of  America 
Commodity  Command  Standard  System 
Control  Data  Corporation 
Contractor  Deficiency  Report 
Commander-in-Chief 
Common  Business  Oriented  Language 
Conference  on  Data  Systems  Language 
Continental  United  States 
Central  Processing  Unit 


DAAS  Defense  Automatic  Addressing  System 

DAASO  Defense  Automatic  Addressing  System  Office 


1  Military  Standard  Requisitioning  and  Issue  Procedures. 
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D>TSY 

DRMS  Automated  Information  System 

DAR 

Destination  Acceptance  Report 

DBM 

Data  Base  Machine 

DBMS 

Data  Base  Management  System 

DCA 

Defense  Communications  Agency 

DC  AS 

Defense  Contract  Administration  Service 

DCASR 

Defense  Contract  Administration  Service  Region 

DCSC 

Defense  Construction  Supply  Center 

DDBMS 

Distributed  Data  Base  Management  System 

DDF 

Data  Descriptive  File 

DDL 

Data  Definition  Language 

DDN 

Defense  Data  Network 

DEPRA 

Defense  European  and  Pacific  Redistribution  Activity 

DFARS 

Defense  Federal  Acquisition  Regulation  Supplement 

DIAL 

Data  Interchange  at  the  Application  Level 

DIDS 

Defense  Integrated  Data  System 

DLA 

Defense  Logistics  Agency 

DLANET 

Defense  Logistics  Agency  Telecommunications  Network 

DLSC 

Defense  Logistics  Services  Center 

DLSS 

Defense  Logistics  Standard  Systems 

DLSSO 

Defense  Logistics  Standard  Systems  Office 

DML 

Data  Manipulation  Language 

DMS 

Data  Management  System 

DoD 

Department  of  Defense 

DoDAAD 

Department  of  Defense  Activity  Address  Directory 

DoDAAF 

Department  of  Defense  Activity  Address  File 

DoDD 

Department  of  Defense  Directive 

DoDI 

Department  of  Defense  Instruction 

DRMO 

Defense  Reutilization  and  Marketing  Office 

DRMS 

Defense  Reutilization  and  Marketing  Service 

DTS 

Defense  Transportation  System 

EBDI  Electronic  Business  Data  Interchange 

EXPRESS  (Data)  Extraction,  Processing,  and  Restructuring  System 

FAA  Federal  Aviation  Administration 

FAD  Force  Activity  Designator 

FAR  Federal  Acquisition  Regulation 

FEP  Front-End  Processor 


FIRMR 

Federal  Information  Resources  Management  Regulation 

FMS 

Foreign  Military  Sales 

4GL 

Fourth-Generation  Language 

FSC 

Federal  Supply  Class 

GBL 

Government  Bill  of  Lading 

GP 

Gateway  Processor 

GSA 

General  Services  Administration 

IBM 

International  Business  Machines  Corporation 

ICF 

Interchange  Form 

ICP 

Inventory  Control  Point 

IDC 

In-transit  Data  Cards 

IGES 

Initial  Graphics  Exchange  Specification 

IGP 

Intelligent  Gateway  Processor 

ILCS 

International  Logistics  Communications  System 

IM 

Inventory  Manager 

IMM 

Integrated  Materiel  Manager 

IRIS 

Interrogation  Requirements  Information  System 

IRM 

Information  Resources  Management 

ISDN 

Integrated  Services  Data  Network 

ISO 

International  Standards  Organization 

JCS 

Joint  Chiefs  of  Staff 

JDA 

Joint  Deployment  Agency 

JDS 

Joint  Deployment  System 

JOPES 

Joint  Operations,  Planning,  and  Execution  System 

kbps 

kilobytes  per  second 

L&MM 

Logistics  and  Materiel  Management 

LAN 

Local  Area  Network 

LASE 

Logistics  Assets  Support  Estimate 

LIDS 

Logistics  Information  Data  Service 

LIF 

Logistics  Intelligence  File 

LOGDESMAP 

Logistics  Data  Element  Standardization  and 
Management  Program 

LOGDRMS 

Logistics  Data  Resource  Management  System 

LOGNET 

Logistics  Network 

LSAO 

Logistics  Systems  Analysis  Office 
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M3S 

MAC 

MAISRC 

MAP  AD 

MAPAF 

MCDN 

MCWI 

MILSBILLS 

MILSCAP 

MILSPETS 

MILSTAMP 

MILSTEP 


Marine  Corps  Standard  Supply  System 
Military  Airlift  Command 

Major  Automated  Information  System  Review  Council 

Military  Assistance  Program  Address  Directory 

Military  Assistance  Program  Address  File 

Marine  Corps  Data  Network 

Motor  Carrier  Waybill  Interchange 

Military  Standard  Billing  System 

Military  Standard  Contract  Administration  Procedures 

Military  Standard  Petroleum  System 

Military  Standard  Transportation  and  Movement 

Procedures 

Military  Supply  and  Transportation  Evaluation 
Procedures 


MILSTRAP 

MILSTRIP 

MLDS 

MODELS 

MOV 

MRAD 

MRASDRS 

MRC 

MRO 

MRP 

MSC 

MTMC 

MTMR 


Military  Standard  Transaction  Reporting  and 
Accounting  Procedures 

Military  Standard  Requisitioning  and  Issue  Procedures 

Multi-Lingual  Database  System 

Modernization  of  DEfense  Logistics  Standard  Systems 

Materiel  Obligation  Validation 

Materiel  Receipt  Acknowledgment  Document 

Materiel  Receipt  Acknowledgment  and  Supply 

Discrepancy  Reporting  System 

Materiel  Release  Confirmation 

Materiel  Release  Order 

Materiel  Returns  Program 

Military  Sealift  Command 

Military  Traffic  Management  Command 

Military  Traffic  Management  Regulation 


NARF 

NASA 

NAVSUP 

NBS 

NDL 

NMCS 

NSC 

NSN 


Naval  Air  Rework  Facility 

National  Aeronautics  and  Space  Administration 

Naval  Supply  Systems  Command 

National  Bureau  of  Standards 

Network  Database  Language 

Not  Mission  Capable  Supply 

Naval  Supply  Center 

National  Stock  Number 
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OCONUS 

Outside  the  Continental  United  States 

O-D 

Origin-Destination 

ODASD(L&MM) 

Office  of  the  Deputy  Assistant  Secretary  of  Defense 
(Logistics  and  Materiel  Management) 

OJCS 

Organization  of  the  Joint  Chiefs  of  Staff 

OMB 

Office  of  Management  and  Budget 

OSD 

Office  of  the  Secretary  of  Defense 

OSI 

Open  Systems  Interconnection 

PAD 

Packet  Assembler/Disassembler 

PC 

Personal  Computer 

PCO 

Procurement  Contracting  Officer 

PICA 

Primary  Inventory  Control  Activity 

PIP 

Physical  Inventory  Program 

PMCL 

Proposed  MILSTRIP  Change  Letter 

POM 

Program  Objective  Memoranda 

PPBS 

Planning,  Programming,  and  Budgeting  System 

QDR 

Quality  Deficiency  Report 

R&D 

Research  anc  Development 

R&M 

Reutilization  and  Marketing 

RDD 

Required  Delivery  Date 

RDF 

Revised  Delivery  Forecast 

RDL 

Relational  Database  Language 

RM 

Reference  Model 

ROD 

Report  of  Discrepancy 

RWI 

Rail  Waybill  Interchange 

S/A 

Service/Agency 

SAMMS 

Standard  Automated  Materiel  Management  System 

SC&D 

Stock  Control  and  Distribution 

SICA 

Secondary  Inventory  Control  Activity 

SIWSM 

Secondary  Item  Weapons  System  Management 

SMPG 

Supply  Management  Policy  Group 

SPAR 

Stock  Point  ADP  Replacement 

SPLICE 

Stock  Point  Logistics  Integrated  Communications 
Environment 
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SPN 

SPR 

SQL 


Shipment  Performance  Notice 
Special  Program  Requirement 
Structured  Query  Language 


* 


TCMD 

Transportation  Control  and  Movement  Data 

TCN 

Transportation  Control  Number 

TCO 

Termination  Contracting  Officer 

TDR 

Transportation  Discrepancy  Report 

TOA 

Transportation  Operating  Agencies 

ucs 

Uniform  Communications  Standard  (for  retail  food 
industry) 

UMMTPS 

Uniform  Materiel  Movement  and  Issue  Priority  System 

WBS 

Work  Breakdown  Structure 

WINS 

Warehouse  Information  Network  Standards 

WWMCCS 

Worldwide  Military  Command  and  Control  System 
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